Interesting benchmark performance (was RE: Pitiful benchmark perf ormance)

[Scott Lystig Fritchie]

>>>>> "uw" == Ulf Wiger <etxuwig@REDACTED> writes:

uw> Another option could be to allow "high-priority" ports, that are
uw> polled e.g. just before checking the normal priority process queue
uw> -- or just after, to reduce the starvation risk.

There was a conversation not long ago over in comp.lang.functional
about managing global state.  One person noted that the latency to
retrieve some "global" state from process S by process C can be a
high-latency operation: it may be a while before S is scheduled to
run, and when S sends its reply, it may be a while before C is
scheduled to run again.

A stray thought this weekend suggested a scheduling mechanism similar
to doors, which are found in Spring, Solaris, and (I think) Linux.
Doors have *very* low latency because the normal process scheduler is
short-circuited: the door server is scheduled to run immediately after
the client executes door_call(), and the client is rescheduled
immediately after the server executes door_return().  From a
wall-clock point of view, a door call looks an awful lot like a local
procedure call: there is process context switching during the call &
return, but they happen without interference from the regular
scheduling algorithm(s).

Doors are a synchronous communication mechanism.  Erlang's are
asynchronous.  If a lower-latency communication scheme were added onto
Erlang, how would you do it to get round trip times door-like?

1. The server process has an attribute that would cause it to preempt
the message sending process immediately.  When the server process
yields or blocks, the message sending process is the next one
scheduled so that it can get its reply right away.

There are a couple of problems with this, I guess.  One, there's no
guarantee that the server will reply to the client right away.  (But
if you want door-like performance, the server must have an answer
right away.  Caveat emptor.)  Two, every message sent to the server
would be handled this way.  This may or may not be bad.

2. Use a new syntactic thingie to explicitly denote door-like
behavior.  For example, use "Pid !! Message".

It's an icky idea, but I thought I ought to mention it.  It may even
have merit, somehow.  {shrug}

3. Have the server process have a second "address" to receive
messages.  Messages received via the real pid make no change in
scheduling.  Messages received via a second pid (pseudo-pid?) would
cause door-like scheduling to occur.

This would be a weird thing for Erlang: messages sent to two different
pids actually get delivered to the same mailbox for the same process.
However, it doesn't solve the problem of how to get door-like
scheduling behavior when sending a reply back to the client ... unless
the client has a pseudo-pid, too.

4. None of the above.

-Scott
---
Scott Lystig Fritchie
Professional Governing: Is It Faked?