From rgentlem@hsph.harvard.edu  Fri Apr 23 14:33:52 1999
From: rgentlem@hsph.harvard.edu (Robert Gentleman)
Date: Fri, 23 Apr 1999 09:33:52 -0400 (EDT)
Subject: options and other things
In-Reply-To: <x2ogkggw1p.fsf@blueberry.kubism.ku.dk>
Message-ID: <Pine.SV4.4.05.9904230925260.20965-100000@hsph.harvard.edu>



On 22 Apr 1999, Peter Dalgaard BSA wrote:

> Robert Gentleman <rgentlem@hsph.harvard.edu> writes:
> 
> >  Duncan has said that in S, when he threaded it, options was a frame 0
> > object and frame 0 was thread specific. We don't really have frames.
> > Conceptually it seems that we are going to have to stick an environment
> > between GlobalEnv and any evaluation envs where that environment 
> > contains thread specific items (perhaps all assignments along that
> > thread).
> 
> Hmm. Ross has also been talking about "frame 0" when talking about
> attachments to position 1. Does that fit in?
> 
> If I get the picture right (I've never tried threads in S), there may
> be an alternative where the thread-specific environment sits on top of
> the the environment from which the thread is started, rather than
> GlobalEnv.
> 
Brian's comment is correct, only Duncan and John ever played with threaded
S and it currently doesn't work with some high probability (and Duncan
said he didn't think it ever would be publicly available).

I guess what I'm thinking is that all threads get started from GlobalEnv,
but that there has to be an extra thread specific env stuck in right
on top of GlobalEnv and before any evaluation envs (so that thread 
specific info can be handled appropriately).

However, having done a little reading over the past few days I'm a bit
discouraged about how difficult it will be to get this stuff correct.
According to at least one author, threads are hard but they are infinitely
easier than signal catching/exception handling. So making a function
thread-safe is possible (not all C level ones that we use are) making
it reentrant on an asynchronous signal is much more difficult.

I am also coming quickly to the belief that POSIX might be the right
coding standard for R. It at least has some standard stuff for letting
you know (at compile time) what level of thread safety is available in
the C library. 

Does that have bad implications for you and Guido, Brian? I'm a bit
worried because alot of the signal handling is if-def'd for Unix only.
Perhaps it should shift and be if-def'd for the correct level of 
POSIX?

What about the Mac?

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


options and other things
Robert Gentleman