On Thu, 30 Mar 2006, Dag-Erling [iso-8859-1] Sm?rgrav wrote: > Daniel Eischen <[EMAIL PROTECTED]> writes: > > Log: > > Account for recent changes in namespace.h. Use _pthread_create > > instead of pthread_create. > > I'm not sure this is correct. When we're inside libpthread or libthr, > we want to use the underscore versions of pthread_*() so we're sure > that we're referring to ourself and not to some third-party pthred > library that may have been mixed in somehow, but outside of it, we > want to refer to whichever pthread library the application developer > has chosen to use (he may even have his own compiled into the > application - been there, done that). I believe the correct fix in > this case is to move <pthread.h> below "un-namespace.h".
I don't think this is the right thing to do. We should take the same approach that libc takes. There are some subtleties with using the underscore versions of some of these functions, for instance _pthread_mutex_init. This creates a special mutex that puts a thread in a critical region when the mutex is locked. Signals are deferred. The consumer of librt doesn't know that mutexes, CVs, and threads are created behind the scenes, so he doesn't instrument his code with pthread_cleanup_push(), pthread_sigmask(), etc. Even if he did, there is no API for him to cleanup librt state. It may be possible to protect the necessary aio, timer, and mq functions with pthread_sigmask() and cleanup handlers, but I haven't looked at how much overhead this would add. -- DE _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
