scsh-users
[Top] [All Lists]

Re: Select in 0.6

To: Martin Gasbichler <gasbichl@informatik.uni-tuebingen.de>
Subject: Re: Select in 0.6
From: "Brian D. Carlstrom" <bdc@zurich.ai.mit.edu>
Date: Thu, 9 Aug 2001 11:20:36 -0700
Cc: scsh@zurich.ai.mit.edu
Reply-to: "Brian D. Carlstrom" <bdc@ai.mit.edu>
Martin Gasbichler writes:

 > 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.

To me threads aren't real unless they truly can run concurrently on a
multi-processor. If s48 is ever going to do that, they won't be so
lightweight. Obviously you can multiplex lightweight threads on top real
threads. I know some people just like threads for a cleaner programming
model, which is nice, and in which case you don't need select.

 > 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.

sure, but it won't scale on a big box. of course, you can run N copies
for N processors but...

 > 
 > 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?

The OS does in my opinion, if you agree that threads are for
multi-processing. if you feel that they are simply a programming
simplification, then it can be your run-time environment.

 > 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.

So then I'm fine with it, as long as I have a way to multiplex N sockets
over M threads where N>>M. 

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

I agree select itself is weird. I don't care if it's select or poll or
/dev/poll or whatever. Even s48 is weird probably if it's not using poll
now, I'd have to remember the reasons why.

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

So like I said, I'm fine with as long is there is a way to decouple
threads so there isn't a 1-to-1 mapping to ports.

-bri

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