Re: [Chicken-users] Posix threading

[Alex Shinn]

At Fri, 11 Mar 2005 00:53:21 +0000, Julian Morrison wrote:
> 
> Toby Butzon wrote:
> 
> >I'm new to "real" Scheme programming[1], but I'm quite surprised
> >that it doesn't use posix/native threading.
> >
> Some of the interpreted schemes probably do. I haven't looked. Posix 
> threading with dynamic code is perfectly possible, I know that java and 
> ocaml both use Posix threads.

Gauche and Guile both do, by providing a separate VM for each thread.
This means you can't invoke a continuation from a thread other than
the one in which it was created, but threads always introduce
complications.

[I very strongly recommend Gauche over Guile if you decide you must
have native threads, but see below.]

> > for, say, a simple webserver, I can't imagine notusing threads

The most proliferant webserver on the net is not multi-threaded, it's
multi-processed.

Yet another approach is to use select and non-blocking I/O.

Threads vs. select is one of your classic Holy Wars.  Here's a good
comparison of different approaches:

  http://www.cs.nyu.edu/rgrimm/teaching/fa03-web/091603.pdf

When you combine Chicken's interpreter threads with non-blocking I/O,
(i.e. what you get with the tcp-server egg) you get the approach the
above paper refers to as SEDA.

This is easy to use and potentially faster than native threads (POSIX
threads are rather slow and heavy).  To see that it avoids blocking,
consider a simple echo server:

$ cat echoserver.scm
#! /usr/local/bin/csi -script-meta
(require-extension tcp-server)
((make-tcp-server 
  (tcp-listen 5050) 
  (lambda () (print (read-line))))
 #t)

This reads one line from a connection and echos it back.  You can
connect with multiple telnet clients at once and it handles them all.

As a stronger test, consider a client that sends and flushes only a
partial line, waits for the user to hit enter, then sends the rest of
the line:

$ cat echoclient.scm
#! /usr/local/bin/csi -script-meta
(require-extension tcp posix)
(define-values (in out) (tcp-connect "localhost" 5050))
(display "process-id: " out)
(flush-output out)
(read-line (current-input-port))
(display (current-process-id) out)
(newline out)
(flush-output out)
(print (read-line in))

Even though each server thread is calling read-line, which doesn't
return until we get a full line of input, you can still interleave any
number of these clients.

The disadvantages of this over native threads is that other system
calls can block.  *Usually* I/O is the only time consuming system
call, and other calls should return right away, but if the kernel
hangs on something like a disconnected NFS server you have to wait for
it to time out.

This also doesn't take advantage of multiple CPU's, but single CPU is
still the common case.  And if you have multiple CPU's you can always
combine interpreter threads with multiple processes.

-- 
Alex