[been on holiday and just found this email... sorry for slow response]
On Sun, 29 Feb 2004, Rocco Caputo wrote:
> On Sat, Feb 14, 2004 at 06:53:44AM -0500, [EMAIL PROTECTED] wrote:
> >
> > Taking Chris' question further... why not implement wait queues (I'm
> > thinking along the lines of NT). Any session could declare it's interest
> > on a waitable object... and anyone with a reference to that object could
> > call wakeup on it. SIGCHLD handling is therefore just a special
> > case of this - you have a handle on the process, register you want to wait
> > on it. When the pid dies, the object referring to that PID could get a
> > wakeup event. If the waitqueue is empty, the process vaporises in a puff
> > of logic. Else the sessions that declared interest get woken.
>
> I've been skimming the web about wait queues, and they're mostly
> kernel and driver synchronization things. The web seems to think
> they're more a Linux dealie than an NT one, and the name "wait queue"
> seems synonymous to "channel" in other UNIXy operating systems.
mostly true. channel is what good ol' sunos/bsd used to call it, but it
was a bit primitive. NT has a fairly advanced system where any object
(e.g. a Process handle) is Waitable, which means that you can issue wait
upon that object with various different flavours of wakeup/mutex
requested.
>
> I'm also confused by process going away when a wait queue is empty,
> although as I write this I suppose "empty wait queue" means nothing
> has subscribed interest to the process.
Sorry - I was leaping forward in my analogy way too fast. What I was
trying to say there was that a session (a.k.a process) dies, it currently
posts a signal to the parent. Instead of doing that, it could just issue a
wakeup to *it's own* wait queue. If the waitqueue is empty (i.e. nobody
has declared interest in sigchild), then the session can immediately
garbage collect.
>
> So I'm going to list what I think you're saying about wait queues,
> with some code that illustrates my understanding of them so far. Your
> job, should you choose to accept it, is to explain where I'm off.
I think that your examples make sense, although I need to read them when
I've had more coffee... the key thing is for a session to be able to say
that it's blocked waiting for a waitqueue to do something and that to be a
valid state.
Nick.
> So.
>
> Sessions would create wait queue instances rather than use Kernel
> methods to watch resources.
>
> $heap->{fh_watcher} =
> WQueue::File->new($handle, "r", "event", @optional_etc);
>
> instead of
>
> $kernel->select_read($handle, "event", @optional_etc);
>
> and
>
> delete $heap->{fh_watcher};
>
> instead of
>
> $kernel->select_read($handle);
>
> Sessions stay around as long as they have at least one wait queue.
>
> Wait queues are a form of IPC. Other sessions can trigger them if
> they can find a reference to them.
>
> $global{23} = WQueue::Event->new("event");
>
> and another session can trigger that with
>
> $global{23}->enqueue(@parameters);
>
> which would replace
>
> $kernel->post(23 => event => @parameters);
>
> Signals would work similarly, but the OS would call enqueue().
>
> $heap->{sigint_queue} = WQueue::Signal->new(INT => "event");
>
> Alarms:
>
> my $before_you_go_go = time() + 3600;
> $heap->{wake_me_up} = WQueue::Alarm->new($before_you_go_go);
>
> and other stuff.
>
>
