Date: Tue, 20 Jan 2004 01:02:12 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Craig Rodrigues <rodrigc@crodrigues.org> Cc: freebsd-threads@freebsd.org Subject: Re: sem_wait() is a cancellation point in libkse? Message-ID: <Pine.GSO.4.10.10401200057220.14763-100000@pcnet5.pcnet.com> In-Reply-To: <20040120053945.GA4096@crodrigues.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 20 Jan 2004, Craig Rodrigues wrote: > Hi, > > I am trying to learn about pthread cancellation points, > and am reading "Multithreaded Programming with PThreads" by > Bil Lewis. In chapter 10 of this book, it states > that sem_wait() should be implemented as a pthread > cancellation point. > > I am not sure that sem_wait() is implemented as > a cancellation point in libkse. > > I looked again at some of the Linux NPTL tests > which I ported to FreeBSD: > > http://crodrigues.org/freebsd/nptl-tests.tar.gz > > > The tst-cancel12 test seems to be failing. > In this test, a thread is spawned with > pthread_create(), and then soon after > pthread_create(), pthread_cancel() is called > on this thread. > > Inside the thread, sem_wait() is called. > The test is expecting that the thread should > immediately exit at the sem_wait() call because > sem_wait() should be a cancellation point. > However, the thread does not exist after calling > sem_wait(), so the test fails. > > I see that in libkse's thr_sem.c, that there > is a _sem_wait() which looks like it is doing > cancellation stuff, but it doesn't > seem to be working. > > Am I misunderstanding how this should work? 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. In short, we know about this. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10401200057220.14763-100000>