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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._