Date: Tue, 22 Oct 2002 11:55:57 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bruce M Simpson <bms@spc.org> Cc: Linus Kendall <linus@angliaab.se>, Peter Pentchev <roam@ringlet.net>, freebsd-hackers@FreeBSD.ORG Subject: Re: PThreads problem Message-ID: <3DB59F3D.45AD05B1@mindspring.com> References: <1035200159.24315.13.camel@bilbo> <20021021124520.GS389@straylight.oblivion.bg> <1035206648.24315.20.camel@bilbo> <20021021134834.GA41198@straylight.oblivion.bg> <20021021135045.GB41198@straylight.oblivion.bg> <1035218026.24330.33.camel@bilbo> <20021021194453.GB377@straylight.oblivion.bg> <1035232308.24315.37.camel@bilbo> <3DB46BB8.46401DF5@mindspring.com> <20021022113132.GB16068@spc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? There is very little in the way of signals which are guaranteed to work, when you are using threads. The best approach is to not use signals and threads together. If you have to use signals for something (in this case, you are building a simple timer mechanism using alarm/SIGALRM), then it is best to trap the signal to a handler, and have the hander do no work whatsoever, other than (1) noting the signal occurred in a volatile marker, and, possibly, (2) triggering a worker thread to act on the signal having occurred, and do the processing which you normally would have done in the signal handler in that thread, instead. -- Terry 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?3DB59F3D.45AD05B1>