sem_wait() is a cancellation point in libkse?

[Craig Rodrigues]

On Tue, Jan 20, 2004 at 01:02:12AM -0500, Daniel Eischen wrote:
> > is a _sem_wait() which looks like it is doing
> > cancellation stuff, but it doesn't
> > seem to be working.
> > 
> libc uses strong symbols for sem_wait which override
> the weak symbols that libpthread is using.  The sem_wait
> in libc isn't a cancellation point yet.  I think the
> sem_foo stuff in libc should be refactored to just make
> the system calls (like semop/semctl) and not know about
> waiting threads.  The threads libraries can wrap them
> if they want to provide cancellation points and faster
> userland thread switches for (process scope) thread
> waits/wakeups.


The thread libraries already seem to wrap sem_wait().

It is in:
src/lib/libc_r/uthread/uthread_sem.c
src/lib/libthr/thread/thr_sem.c
src/lib/libpthread/thread/thr_sem.c

sem_wait() in those files is implemented as _sem_wait(), and
is a proper cancellation point.

Is there anything wrong with making sem_wait() a weak symbol
in libc?  I tried the following patch, and it works
quite nicely, i.e. tst-cancel12 in the NPTL tests now
succeeds.


--- sem.c.orig	Tue Jan 20 11:37:35 2004
+++ sem.c	Tue Jan 20 11:44:20 2004
@@ -53,6 +53,8 @@
 static LIST_HEAD(, sem) named_sems = LIST_HEAD_INITIALIZER(&named_sems);
 static pthread_mutex_t named_sems_mtx = PTHREAD_MUTEX_INITIALIZER;
 
+__weak_reference(_sem_wait, sem_wait);
+
 static void
 sem_free(sem_t sem)
 {
@@ -255,7 +257,7 @@
 }
 
 int
-sem_wait(sem_t *sem)
+_sem_wait(sem_t *sem)
 {
 	int	retval;
 


-- 
Craig Rodrigues        
http://crodrigues.org
rodrigc at crodrigues.org