Date: Thu, 28 Feb 2002 19:37:26 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alfred Perlstein <bright@mu.org> Cc: smp@FreeBSD.ORG, dillon@FreeBSD.ORG, jhb@FreeBSD.ORG, smp@FreeBSD.ORG, Chad David <davidc@acns.ab.ca> Subject: Re: select/poll locking wrong? Message-ID: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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.
This implies that we can add a TAILQ list to each thread and associate
selinfo records with the thread (or 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.
Is this what you are saying? I am still somewhat confused as to the
distinction between thread and process in the context of select().
-Matt
Matthew Dillon
<dillon@backplane.com>
: One global lock for select/poll operations. (BSD/os style)
:
: cv_wait* interlocks with the global lock.
:
: struct selinfo is modified (and bloated :() to contain a pointer
: to the thread as well as a TAILQ so all the selinfo's registered
: to a particular thread are on a list hung off of that thread
: struct.
:
: all the lists are protected by the select mutex.
:
: selrecord is modified to link the selinfo off the thread and set
: the back pointer to the thread. (under select lock)
:
: selwakeup is modified to grab the select lock, do its checks.
:
: On return from from select/poll you walk the list and point all
: the selinfos to null and remove them from yourself.
:
:basically, every time you see:
: sip->si_pid = 0;
:you want to remove that selinfo from the list hung off the proc.
:
:each time you see
: sip->si_pid = mypid;
:you want to link that selinfo into yourself.
:
:Because selwakeup is only called when someone is interested in
:the socket/pipe/whatever it's not going to be a global contention
:point other than with other threads heavily engaged in select/poll
:activity.
:
:
:I'd really appreciate some feedback, I'd like it even more if someone
:did this work, failing that I'll take a shot at it.
:
:Or is this not going to work? :)
:
:thanks,
:--
:-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?200203010337.g213bQv40727>