definition of R_problem_buf in S.h (PR#210)

[Duncan Temple Lang]

> 
> Duncan Temple Lang <duncan@rice.research.bell-labs.com> writes:
> 
> > I would vote for (2). If we go to multiple evaluators as some of us
> > were discussing recently, evaluator-specific statics will need to be
> > removed.
> 
> Hm. That won't help, will it? We'd have one static object instead
> of several. If threads try to step on eachothers toes it wouldn't
> prevent it, just allow them to do it from within different functions!
> 
> What one would really need is a way to generate the buffer
> dynamically *inside* the function call. Or setup PROBLEM to do some
> kind of resource locking, in which case it doesn't really matter
> whether we use (1) or (2)? Or...?
> 


Absolutely. I was just thinking of not having many statics but that we
could deal with a single one by adding it to the Evaluator
structure. In this way, there is a single one per evaluator and at
present this is adequate. If we need more, we introduce a stack or
linked list.  If we dynamically generate the buffer in the call, then
we will have to change the arguments, etc. to pass it out to other
routines. Otherwise, if we use the statics to communicate the new
buffer we are no better off, except for the dynamic allocation
avoiding the buffer overflow.


Robert will likely be doing things with all of this via
his exception/handler mechanism also.

-- 
_______________________________________________________________

Duncan Temple Lang                duncan@research.bell-labs.com
Bell Labs, Lucent Technologies    office: (908)582-3217
700 Mountain Avenue, Room 2C-259  fax:    (908)582-3340
Murray Hill, NJ  07974-2070       
         http://cm.bell-labs.com/stat/duncan

      Languages shape the way we think, and determine what 
      we can think about -- Benjamin Whorf
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._