Date: Mon, 13 Aug 2001 13:18:52 -0400 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Jonathan Chen <jon@freebsd.org> Cc: hackers@freebsd.org Subject: Re: pthreads and poll() Message-ID: <3B780BFC.F2BA0A9B@vigrid.com> References: <20010813120455.A63309@enterprise.spock.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jonathan Chen wrote: > Yesterday marked my first attempt at mixing poll() with pthreads. > Needless to say, things did not work out the way I wanted them to. So, I > began the task of finding out the behaviors of various OSes to see if my > code would run fine on them. For your reference and amusement, my results > and test code is included below. > > I think that waking only one thread up is the correct behavior, or is there > something that toggles which behavior I want? Perhaps someone with access > to the POSIX standard would care to confirm what the Right Thing is? > Perhaps that someone would then proceed to fix all the incorrect > implementations... or am I asking too much? :) > > Looks like I'm going to have to swear off mixing poll() with pthreads for > at least two years if I want my code to be portable... We don't provide locking for fd's any longer (I thought this was only in -current, but your results seem to indicate otherwise). If we did, only one thread would wake up. The mistake in your sample seems to be that you're having all threads block on the same fd. Why? We took the approach in -current that it is up to the application to provide locking for fd's. Our libc_r also wraps poll() into non-blocking calls which allows the other threads to run and "block" on the same fd. When we get blocking down in the kernel (KSEs or a linuxthreads like approach), I'm not exactly sure what would happen. From your results (linuxthreads under FreeBSD), it looks like it should behave as you expect. > Aside: I thought that linuxthreads == Linux's implementation of pthreads? > Now why do they behave differently? It depends on how things get woken up in the kernel. I don't think I would rely on any particular behaviour... -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B780BFC.F2BA0A9B>