On 6/21/07, Andrew Geweke <[EMAIL PROTECTED]> wrote:
(I tried searching the list archives for this, but couldn't find
anything relevant.)
I've been delving through the guts of the IO implementation (in order
to fix a different bug), and, as far as I can tell, JRuby's IO
objects aren't thread-safe, unless I'm missing something big (which
could very well be the case -- please tell me if so!).
I don't even mean that they aren't guaranteed to (e.g.) output all
bytes from one thread's "write" call before all bytes from another
thread's "write" call; I mean that use from multiple threads can
apparently cause arbitrary problems, like dropped data, etc. (For
example, there are apparently-unlocked calls to write buffered data,
then clear the buffer, etc.; if another thread adds to the buffer in
the interim, its data will disappear.) See for example
org.jruby.util.IOHandlerSeekable.syswrite().
My questions:
1. In MRI, are these objects thread-safe -- at least in terms of
not dropping data or getting corrupted internally? (Does its use of
green threads perhaps guarantee this?)
MRI has green threads and does not support native threads. So it does
not need to be thread safe.
2. Should JRuby's implementation of these objects be thread-safe?
All of them? Some of them? Just $stdout/$stderr?
Yes. All of them within reason.
Please file a bug in Jira for this.
-Tom
3. If the answers to the above are both "no", then does this
really mean that unless you lock every single call to (e.g.) puts or
printf, you risk losing data or corrupting the internal state of
$stdout/$stderr?
I very much appreciate any feedback -- I am more than happy to make
any relevant fixes, but want to make sure I'm doing things the right
way before I touch it.
Thanks!
Andrew
P.S.: JRuby is an incredible platform. I think I am going to write
all code in it from now on, period. :-D
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
--
Blog: http://www.bloglines.com/blog/ThomasEEnebo
Email: [EMAIL PROTECTED] , [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email