[prev in list] [next in list] [prev in thread] [next in thread] 

List:       eros-arch
Subject:    Re: [eros-arch] rendezvous queues
From:       "Jonathan S. Shapiro" <shap () eros-os ! org>
Date:       2003-12-31 12:19:05
Message-ID: 1072873144.18546.138.camel () deskjob ! eros-os ! org
[Download RAW message or body]

On Sun, 2003-12-28 at 00:25, Charles Landau wrote:
> >Here is a slightly expanded description. ...
> 
> So if I understand correctly, one fundamental difference between a 
> rendezvous queue and the sort of data structures...

Your description seems accurate. Actually, the two proposals aren't all
that different in practice, since the decongester needs a place to
thread things together and using some slot in the process root for this
purpose would seem to make sense.

> Another difference: The Apache pattern's data structures 
> (stack/queue) are all persistent. The rendezvous queue's data 
> structures are not persistent; on a restart, the worker processes, 
> being in the running state, will re-enqueue, though perhaps not in 
> the same order. I don't see that as a problem.

Actually, the rendezvous queue data structures MUST be persistent, but
they are not kernel persistent. Rather, the decongester is responsible
for implementing their persistence.

The problem here is process table pressure. The kernel needs to be able
to say "process X has been on queue Q for a long time doing nothing. I
need the process table slot, so I'm sending a pair of the form

	(nameof(Q), faultkey(X))

to the decongester. At a later time, I may upcall the decongester asking
it to produce a process that is sleeping on the queue Q.

> Are you saying that a rendezvous queue should be available as an 
> option, or that *all* IPC must be done that way?

Assume for a moment that the decongester design can be made to work. If
so, then I think I'm saying that yes, an option can be done, but an
option is not desirable. I suspect that for existing usage this mostly a
rearrangement of existing data structures. If so, there may not be any
real motivation for eliminating the explicit rendezvous queue in the
normal case.

shap

_______________________________________________
eros-arch mailing list
eros-arch@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/eros-arch
[prev in list] [next in list] [prev in thread] [next in thread]