Date: Wed, 14 Jul 2004 22:50:29 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: alfred@FreeBSD.org Cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_event.c src/sys/sys eventvar.h Message-ID: <200407150550.i6F5oTFx026920@gw.catspoiler.org> In-Reply-To: <20040714210132.GI95729@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14 Jul, Alfred Perlstein wrote: > * Don Lewis <truckman@FreeBSD.org> [040714 13:38] wrote: >> On 14 Jul, Alfred Perlstein wrote: >> > * Doug Rabson <dfr@nlsystems.com> [040714 12:01] wrote: >> >> >> Seems to me that the best thing to do is to defer the psigio() to a >> >> taskqueue that will run in a simpler locking environment. >> > >> > I was thinking that, but I'm worried about "stale delivery", >> > perhaps we need to record the generation count (process start time) >> > in the sigio as well as the request sent, so that we don't send >> > a signal to the wrong process. >> >> This is already handled in the sigio infrastructure. Both struct proc >> and struct pgrp have a list of their potential sigio sources. When the >> process or process group goes away, the exit code disables sigio >> delivery. > > Yes, but if the delivery of the signal becomes async, then we lose > this. Push a reference to the struct sigio onto the taskqueue would be a quick and dirty way of dealing with this. The ugly part is that it would mean adding a reference count and a valid flag to the struct sigio.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200407150550.i6F5oTFx026920>