Date: Tue, 22 Oct 2002 11:28:11 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Peter Pentchev <roam@ringlet.net> Cc: Bruce M Simpson <bms@spc.org>, freebsd-hackers@FreeBSD.ORG Subject: Re: PThreads problem Message-ID: <Pine.GSO.4.10.10210221117150.21131-100000@pcnet1.pcnet.com> In-Reply-To: <20021022123038.GB378@straylight.oblivion.bg>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 22 Oct 2002, Peter Pentchev wrote: > On Tue, Oct 22, 2002 at 12:31:32PM +0100, Bruce M Simpson wrote: > > On Mon, Oct 21, 2002 at 02:03:52PM -0700, Terry Lambert wrote: > > > It is more correct to say that libcurl makes an assumption about > > > signal delivery which is not guaranteed by POSIX, and therefore > > > libcurl will not work with *any* POSIX compliant threads > > > implementation which does not *happen* to work this way. > > > > Would a more correct approach, when dealing with POSIX threads and signals, > > be to make sure signals are delivered to a single thread *expressly for > > that purpose*, and then use POSIX thread primitives (such as mutexes and > > condvars) to communicate the signal conditions to the other threads? > > ..and when you start writing programs which depend on this functionality, > they will not work on any system that does not do it. Part of the problem > is that the linuxthreads approach of different threads as different > processes would require that you deliver each and every signal destined > for a 'worker' thread/process to the designated 'signal handler' > thread/process; I am practically certain that no one in the Linux kernel > crowd would like the idea of redirecting all signals from one process to > another :) Like it or not, what Bruce is suggesting is POSIX behaviour. If Linuxthreads doesn't allow one thread to sigwait or sisgsuspend on a signal, and to have a signal delivered to it (assuming the signal is masked in all other threads), then it is very wrong. Plus, each client thread doesn't necessarily have to do the sigalarm() itself. The timeout server thread can do it based on the smallest timeout in its list of client requests. When a new thread wants to add a timeout, it locks the timeout list, inserts the timeout, unlocks the list, and uses pthread_kill(tsid, SIGALRM) to wakeup the timeout server thread. When the timeout server thread wakes up, it can reevaluate its list of timeout requests, handle any threads that have timed out, and go back to sleep. You can use pthread_kill() to signal any client thread that has timedout. I'm sure there are other ways of doing it, but I don't see why something like the above won't work under Linuxthreads as well. -- 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?Pine.GSO.4.10.10210221117150.21131-100000>