Date: Fri, 20 Oct 95 13:08:43 MET From: marino.ladavac@aut.alcatel.at To: jb%cimaxp1@werple.net.au (John Birrell) Cc: hackers@freebsd.org Subject: Re: NetBSD/FreeBSD (pthreads) Message-ID: <9510201208.AA26365@atuhc16.aut.alcatel.at> In-Reply-To: <199510200208.MAA11995@werple.net.au>; from "John Birrell" at Oct 20, 95 12:11 (noon)
next in thread | previous in thread | raw e-mail | index | archive | help
> > If you get a real blocking operation (ie: one outside the model, etc.), > > then all threads are blocked because the context switcher can't run > Our scheduler runs on signals, so any calls outside the model are interrupted > and the next thread is run. An example of a blocking call that is outside > the pthreads model is msgrcv(). In our implementation, a blocking call to > msgrcv() will block for its time slice and then be interrupted by a SIGVTALRM > so that the next thread runs. The application has to handle the EINTR that is > returned to the thread once it gets to run again. Either that or the > application has to be written to use IPC_NOWAIT. Either way requires a > compromise. Are you sure that the virtual timer keeps running when process is blocked? I would think not. This means that you shouldn't be able to use SIGVTALRM to interrupt this sort of calls. You would have to jacket them (within the pthread library, hopefully) and activate normal timer and await SIGALRM instead. Is this what you have done in your pthread lib rewrite? > > unless it converts the call. Like fstatfs/statfs on a remote but > > down server (yit's not a select()'able operation). > This should still be interruptable by a signal. > -- > John Birrell CIMlogic Pty Ltd > jb@cimlogic.com.au 119 Cecil Street > Ph +61 3 9690 9600 South Melbourne Vic 3205 > Fax +61 3 9690 6650 Australia > Mob +61 18 353 137 /Alby
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9510201208.AA26365>