On Sep 4, 2009, at 12:29 AM, Wolfgang Lux wrote:
Fred Kiefer wrote:
What do others think, is it worthwhile to hide these implementation
details via another indirection or not? I am still in favour of
using an
opaque data type here. On systems like FreeBSD where
pthread_mutex_t is
itself a pointer we could use that directly and on other systems we
have
one additional malloc and free call per mutex. And where the
structure
fits into your one or two words we could even put the value into the
ivar directly.
I absolutely agree with you here. The interface should not expose
any of
the implementation details unless there is a really pressing need to
do
so. I understand David's reasoning that the approach with an opaque
pointer may lead to additional cache misses on FreeBSD (and apparently
OpenBSD as well), but without hard figures -- i.e., benchmarks for
real
world programs making intensive use of NSLocks that show a substantial
performance improvement -- I consider this kind of coding premature
optimization which should be avoided.
Why not fix any problems in the ObjC runtime source? The point of
those interfaces was to hide thread implementation issues across
platforms and provide all ObjC programs with thread capability.
Scott
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
