Date: Thu, 28 Feb 2002 20:06:03 -0800 From: Alfred Perlstein <bright@mu.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: smp@FreeBSD.ORG, dillon@FreeBSD.ORG, jhb@FreeBSD.ORG, Chad David <davidc@acns.ab.ca> Subject: Re: select/poll locking wrong? Message-ID: <20020301040603.GE77980@elvis.mu.org> In-Reply-To: <200203010337.g213bQv40727@apollo.backplane.com> References: <20020227111605.GH80761@elvis.mu.org> <20020227122606.A15980@colnta.acns.ab.ca> <20020227193059.GP80761@elvis.mu.org> <20020227124514.A27497@colnta.acns.ab.ca> <20020227202205.GT80761@elvis.mu.org> <20020227235736.A28776@colnta.acns.ab.ca> <20020228073743.GD80761@elvis.mu.org> <20020228011644.A28982@colnta.acns.ab.ca> <20020228095037.GJ80761@elvis.mu.org> <200203010337.g213bQv40727@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matthew Dillon <dillon@apollo.backplane.com> [020228 19:37] wrote: > You've lost me. I am going to try to rationalize your description. > > si_pid is set to 0 in selwakeup() and set to non-0 in selrecord(). > Apparently, though, si_pid is also cached so if a select() returns > and the event has not occured, si_pid will still be left set to the > last process that requested the event. If the process later goes > away another selrecord() will simply overwrite the cache, otherwise > it uses the selwait conflict domain. Yes. > > The cache appears to be there so select(), when it is getting ready > to return, can avoid traversing the list and removing the events that > have not occured. This results in a potentially stale si_pid because > now the process can exit without doing any further cleanups. Yes, this is why we must now walk the list when leaving select/poll. > This implies that we can add a TAILQ list to each thread and associate > selinfo records with the thread (or process?) Thread, not process. > their si_pid has been > assigned to. When the thread exits, the si_pid & si_thread fields > can be wiped right then and there with a simple traversal so they > aren't left stale. si_pid is going to go away, see below. > Is this what you are saying? I am still somewhat confused as to the > distinction between thread and process in the context of select(). Almost. There is no more si_pid, there will be a si_procp (back pointer to proc struct) and si_proclst (list of all selinfo associated with process). Yuo are correct, we now will have to traverse the list and null out the si_procp on return from select/poll. Forget thread/process, they are all threads. The only reason there is confustion is because si_pid is per-process that's why the thread pointer was added to the selinfo struct. Anyhow, hope that clarifies. Any other ideas or improvements? Any idea on how we can avoid the list traversal at the end of select? -- -Alfred Perlstein [alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020301040603.GE77980>