1) An exception is stored in a global variable, "$!". If multiple
threads have exceptions thrown, is the the thread guaranteed to get
it's own exception (not another threads) when evaluating the "$!". (I
know there is a work around by naming the exception.)
2) Does ruby commonly use global values to pass values...which is not
thread safe (unless it's somehow "thread-local").
3) Is there any plan to use OS-level threads in Ruby 2.0? A simple
thread example I wrote was incredibly slow and I think it was because
many "slow-to-return" OS calls were being made...
thanks,
Justin
> 1) An exception is stored in a global variable, "$!". If multiple
> threads have exceptions thrown, is the the thread guaranteed to get
> it's own exception (not another threads) when evaluating the "$!". (I
> know there is a work around by naming the exception.)
>
> 2) Does ruby commonly use global values to pass values...which is not
> thread safe (unless it's somehow "thread-local").
Don't use globals. I can't think of a single instance where one needs to use
them, though maybe someone else can. So, if you do want to use them, use a
mutex.synchronize block around them.
> 3) Is there any plan to use OS-level threads in Ruby 2.0? A simple
> thread example I wrote was incredibly slow and I think it was because
> many "slow-to-return" OS calls were being made...
Yes. OS level threads are going to be supported in Ruby 2.0.
At the current time, if one has code that is making a lot of calls which will
block, the best alternative is to use a multiprocess model instead of a
multithreaded model.
Kirk Haines
But, yes, variables like $&, $`, $', $1..$n and I've no doubt $! are
really thread-local.
Regards,
Bill
> But, yes, variables like $&, $`, $', $1..$n and I've no doubt $! are
> really thread-local.
Which is cool, I agree, but in general, my position is still to not use
globals, and just sidestep the whole issue.
Kirk Haines
all the vars derived from $~
--
Mauricio Fernandez
Yes.
robert