Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornell!travelers.mail.cornell.edu!news.kei.com!news.mathworks.com!uunet!in1.uu.net!world!decwrl!netcomsv!netcom.com!bakul
From: bakul@netcom.com (Bakul Shah)
Subject: Re: Features for systems programming languages
Message-ID: <bakulD4DFL4.6n8@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <95Feb17.225901est.12684@galapagos.cse.psu.edu> <9502210212.AA25955@clark.lcs.mit.edu>
Date: Tue, 21 Feb 1995 22:24:40 GMT
Lines: 47
Sender: bakul@netcom20.netcom.com

Olin Shivers writes:
>   |  We're working on threads. Everyone wants threads.

Scott Schwartz (?) writes:
>   Not me!  I prefer coroutines.  I've never seen a user-mode threads
>   package that worked reliably.  Under unix, fork() is really the only
>   way to get it right in all cases.

I agree.

Olin Shivers writes:
>- Thread fork costs like a procedure call; fork() is more expensive.

Cost of switching between threads is usually more critical to
performance than the cost of creating/cloning a thread.  Of
course, a coroutine switch will cost a lot less than a process
switch.  Of course, given coroutines and a virtual machine
implementation it is trivial to implement `preemptive' threads of
limited capability. [See below for what I mean by limited]

>- Inter-thread communications uses shared memory. You can pass large, complex
>  data structures just by passing a pointer. Inter-process comm uses
>  pipes, which implies unparsing and reparsing the data into byte streams.

Note that under most versions of unix you can use shared memory
or mapped files for passing large, complex data structures.  No
need for any plumbing.  In fact more versions of Unix provide
shared mem/mapped files than threads.  Mapped files also allow
you to share state between processes that are not clones of each
other.

>- Unix is not designed for threads, you bet. Too much global process state
>  that should be per-thread or not state at all. Hence your comment, "I've
>  never seen..." However, the SRC guys did a pretty solid job of porting
>  their multi-thread env from Topaz or Taos or whatever to native Unix.

The problem here is not too much or too little state but the fact
that this state is not manipulatable by (or even visible to) a
user process.

Can *more* than one of your threads block in a system call?
Without this what a thread can do is limited.  Especially in a
systems programming language.  On a multiprocessor system will I
be able to run multiple threads on multiple processors *at the
same time*?

Bakul Shah <bakul@netcom.com>
