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
>