scsh-users
[Top] [All Lists]

Re: Select in 0.6

To: "Brian D. Carlstrom" <bdc@ai.mit.edu>
Subject: Re: Select in 0.6
From: Martin Gasbichler <gasbichl@informatik.uni-tuebingen.de>
Date: Thu, 09 Aug 2001 19:12:40 +0200
Cc: scsh@zurich.ai.mit.edu
Sender: gasbichl@informatik.uni-tuebingen.de
>>>>> "Brian" == Brian D Carlstrom <bdc@zurich.ai.mit.edu> writes:

Hmm, I received you answer from scsh-news@zurich.ai.mit.edu only and
got only one copy. Whatever this means, I'll answer via
scsh@zurich.ai.mit.edu...

Brian> Martin Gasbichler writes:
>> Select cannot remain as it was since it's a blocking system call which
>> undermines the thread system. We see two options here:

Brian> Is this because s48 doesn't really use threads? That seems to be the
Brian> fatal flaw here if that is the case, not select.

It uses user level threads and this is the cause of the problem,
that's correct.

Brian> So the real con here is that "Pro 1" is false. Having experience in Java
Brian> writing scalable servers, once you reach a few hundred connections, you
Brian> end of reverting back to select (or poll or /dev/poll or NT I/O
Brian> Completion ports) and a worker thread modle.

Why? Threads in Scheme48 are very, very cheap. You cannot compare them
with Java threads. S48's threads allocate only a few bytes and don't
require any work if they wait for I/O.

Note that you already experienced that "real" threads are the wrong way.

Brian> Any server that isn't using select isn't likely to be anything more than
Brian> a toy. You'll be better of using Kawa with JDK 1.4's new I/O package
Brian> than using scsh to write servers.

A new version of the sunet ftp server that uses threads is already
running as primary ftp server of our department. This "toy" is doing a
very good job.

Brian> Since this is all because s48 doesn't have real threads, I'd rather
Brian> pretend to be a C programmer and implement my own application level
Brian> "multi-threading" with select.

Who defines, what real threads are?

Brian> Does s48 use select internally to multi-plex I/O? If so, a different API
Brian> could be used to register app requests for selects with the VM in a
Brian> callback model. I believe X-Windows (or xlib) worked that way. I worked
Brian> on a project that did it like that, I think NT's new model is like that.

Of course, S48 has a select and I/O is processed via this select. The
callback model you request is exactly what you can do using S48's
threads.

Brian> But to me the true goal should be the ability to call any system call
Brian> without too much difference from the C man page so that people can use
Brian> references like Stevens and POSIX to understand what is going on.
Brian> Obviously having a weird thread model and even weirder select is a 
problem.

There is no weird thread model. Select is the weird thing here. And
the question remains: "Is there anybody out there using select"?

Scsh is a mean to provide abstractions over Unix's weaknesses. And
user-level threads fit smoothly into this concept.

-- 
Martin

<Prev in Thread] Current Thread [Next in Thread>