Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA21056; Fri, 19 Jan 96 22:40:34 EST
Received: from JIMI.MIT.EDU by MIT.EDU with SMTP
	id AA09321; Fri, 19 Jan 96 22:40:33 EST
Received: by jimi.MIT.EDU (5.57/4.7) id AA20615; Fri, 19 Jan 96 22:40:42 -0500
Message-Id: <9601200340.AA20615@jimi.MIT.EDU>
To: Vinay Sabharwal <vinay@visigenic.com>
Cc: proven@MIT.EDU
Subject: Re: Your pthread implementation 
In-Reply-To: Your message of "Mon, 15 Jan 1996 18:16:51 PST."
             <QQzyrx25153.199601160217@relay1.UU.NET> 
Date: Fri, 19 Jan 1996 22:40:41 EST
From: Christopher Provenzano  <proven@MIT.EDU>


> Chris
> 
> Thanks for the info.
> 
> A couple of more questions:
> 
> (a) As it turns out, we on occasion WOULD like to redistribute
>     the source code as well.  Based on your copyright notice,
>     it appears that this is legal.  Am I correct ?

Yes.
> 
> (b) Do you have a date for when your implementation goes
>     "production" (ie., comes out of Beta) ?

Not yet. I've got a few more bug fixes I want to put out for one more 
Beta round. Hopefully that will be it for 1_60 making it a very stable
release. My guess is another month. 

> 
> (c) Am I correct in my understanding that the P-thread implementation
>     on OS platforms that don't support native threads is non-preemptive
>     in the sense that a thread that is blocked on a call to an external
>     facility or in an infinite CPU loop won't yield to the 
>     thread scheduler ?

Many system calls have been rewritten so that they do block only the 
thread and not the process. These calls include sleep() and friends, 
all networking I/O, I/O to the pty, select(), wait() and friends and a 
few others. 

As for infinite CPU loops, my implementation is fully preemptible. Threads
are scheduled round robin as the default with a time slice on 100 mseconds.

CAP
