definition of R_problem_buf in S.h (PR#210)
Duncan Temple Lang
Mon, 14 Jun 1999 14:18:58 -0400
> Duncan Temple Lang <email@example.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 firstname.lastname@example.org
Bell Labs, Lucent Technologies office: (908)582-3217
700 Mountain Avenue, Room 2C-259 fax: (908)582-3340
Murray Hill, NJ 07974-2070
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: email@example.com