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

List:       cap-talk
Subject:    Select-like service
From:       Landau, Charles charles.landau () TANDEM ! com
Date:       1998-03-31 19:13:30
[Download RAW message or body]

Jonathan, you can forward this to eros-arch if you want; I don't seem to
have the authority to do so.

If you think about it, you can frequently add appropriate function to
your "support threads". To take the X-server example, if you are
monitoring a connection, maybe there is some computation associated with
that connection that you could/should do before forwarding the event to
the central domain. Thinking about the problem in this way often
improves the structure. You start out motivated by finding something
useful for the support threads to do, and end up with a better
object-oriented design. 

Anticipating your objection: "Oh, what a tangled web we weave, whene're
we attempt to re-use non-object-oriented code." 

Regarding select: it doesn't solve the problem. Your support threads
wait two ways: (1) invoking a start key and waiting for the server
process to become available, and (2) having called, waiting for the
return. Suppose the server serves requests out of order. You could get
in, but not get out for a while. This is also an architectural issue. 

> ----------
> From: 	Jonathan S. Shapiro
> Sent: 	Tuesday, March 31, 1998 3:16 AM
> To: 	eros-arch@eros.cis.upenn.edu
> Subject: 	Select-like service?
> 
> Perhaps it is unwarranted, but I am concerned about thread pressure.
> There seem to be an awful lot of cases where a domain needs a whole
> bunch of support threads whose sole job in life is:
> 
> 	wait for something interesting to happen on a capability
> 	   turn around and kickstart some process
> 
> In general, this structure appears to be necessary for domains that
> must accept input from multiple sources (e.g. X-server: mouse, kbd,
> various connections, etc. etc.).
> 
> The problem is exacerbated by the fact that EROS has a fixed-size
> thread table.  I'm already contemplating going back to a more
> KeyKOS-like design on this issue, but not before my thesis is
> completed.
> 
> With all that as background, I have been pondering whether there might
> be merit to adding a "select" system call (or perhaps a capability),
> which would work as follows:
> 
>    select bit-vector -> bit-vector
> 
> The select() call takes in a bit-vector describing which key registers
> are of interest.  Whenever the object named by the capability in a
> register of interest becomes available, select returns with that bit
> set in the output bit-vector.
> 
> For reference, select is one of the basic demultiplexing mechanisms in
> UNIX.  It ain't an elegant solution, but it's sometimes quite useful.
> 
> The case for making select() a system call is that it's function has
> equal stature to that of the CALL/RETURN/SEND primitives.
> 
> 
> 
> Reactions?
> 
> 
> shap
> 

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