Skip site navigation (1)Skip section navigation (2)
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>