Jim Deville wrote:
-W _level_ sets the warning level. Internally, it sets $VERBOSE to true if -W, -W1 sets $VERBOSE to false and -W0 sets $VERBOSE to nil. If $VERBOSE is nil, no warnings (even those called by Kernel.warn) will be printed.
From what I can gather, -v, --version, -w and -W (-W wit
onRuby External Code Reviewers; Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise
I think the implications of critical= in MRI are more complicated than
just a local lock. It actually stops normal thread scheduling, so other
threads freeze what they're doing. That
Tomas Matousek wrote:
No, Ruby doesn't have any such warning filter. You can place a flag on
RubyContext (via GetOrCreateLibraryData) that remembers for the current runtime
that the warning has already been reported.
I'd expect to do the same in JRuby; it would be a one-time warning for
sure
PM
To: ironruby-core@rubyforge.org
Cc: Tomas Matousek
Subject: RE: [Ironruby-core] Code Review: Thread#raise
Is there a way to get the warning printed just the first time it was executed
in the process? Uses like the get_unique_cookie example below would be called
multiple times, and it would be extr
esday, January 06, 2009 12:42 PM
To: ironruby-core@rubyforge.org
Cc: Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise
Um... other than meta programming (use an if $VERBOSE block to warn, then
redefine the current method to remove the $VERBOSE block)
JD
-Original Me
, January 06, 2009 12:25 PM
To: ironruby-core@rubyforge.org
Cc: Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise
Is there a way to get the warning printed just the first time it was executed
in the process? Uses like the get_unique_cookie example below would be called
multiple times
: ironruby-core@rubyforge.org
Cc: Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise
-W _level_ sets the warning level. Internally, it sets $VERBOSE to true if -W,
-W1 sets $VERBOSE to false and -W0 sets $VERBOSE to nil. If $VERBOSE is nil, no
warnings (even those called by Kernel.warn
06, 2009 11:50 AM
To: ironruby-core@rubyforge.org
Cc: Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise
I agree that critical= can cause problems, and should go away. However, it can
also be used in a reasonably safe way. Something like this. Such usages do not
rely on other
...@rubyforge.org] On Behalf Of Charles Oliver Nutter
Sent: Tuesday, January 06, 2009 10:53 AM
To: ironruby-core@rubyforge.org
Cc: IronRuby External Code Reviewers; Tomas Matousek
Subject: Re: [Ironruby-core] Code Review: Thread#raise
I think the implications of critical= in MRI are more complicated than
just a
I think the implications of critical= in MRI are more complicated than
just a local lock. It actually stops normal thread scheduling, so other
threads freeze what they're doing. That's vastly more intrusive than
just a lock or critical section:
◆ ruby -e "Thread.new { sleep 1; puts Time.now; r
Subject: Re: [Ironruby-core] Code Review: Thread#raise
kill and raise might be a bit of a bother if you add warnings, since
they're used in several libraries without any good replacement other
than reimpl (usually to interrupt stuck IO operations). But yeah, I'd be
on board with an across
Warning sounds reasonable for Thread#kill and Thread#raise. FWIW, Mongrel and
webbrick do use Thread#kill to kill a background thread.
Thread.critical= can actually be used in a sane way for simple synchronization,
like the lock keyword in C#. This is used much more widely, and a warning for
th
kill and raise might be a bit of a bother if you add warnings, since
they're used in several libraries without any good replacement other
than reimpl (usually to interrupt stuck IO operations). But yeah, I'd be
on board with an across-the-board Thread.critical= warning in both JRuby
and IronRub
I think we should at least report a warning when Thread#kill, Thread#raise or
Thread#critical= is called if not eliminating them as Charlie proposed on his
blog.
Tomas
-Original Message-
From: Curt Hagenlocher
Sent: Tuesday, December 30, 2008 10:05 PM
To: Shri Borde; IronRuby External C
Ah, I see; I misunderstood the way that flag was working.
-Original Message-
From: Shri Borde
Sent: Tuesday, December 30, 2008 1:23 PM
To: Curt Hagenlocher; IronRuby External Code Reviewers
Cc: ironruby-core@rubyforge.org
Subject: RE: Code Review: Thread#raise
The terminology I am using
The terminology I am using throughout is synchronous exception would be a
normal Kernel.raise as the thread knows exactly when and where the exception
will occur. Thread#raise is considered to raise an exception asynchronously as
you cannot control exactly when and where the exception will actua
Shouldn't the option "UseThreadAbortForSyncRaise" be called "...ForASyncRaise"?
I think that Thread.raise with no arguments should just inject a RuntimeError
with no message as if $! were nil; this makes more sense than failing. Trying
to reference a "current exception" in another thread is a sc
tfpt review "/shelveset:raise;REDMOND\sborde"
Comment :
Implements Thread#raise using Thread.Abort, and added tests for it
Implemented stress mode (RubyOptions.UseThreadAbortForSyncRaise) which found
more issues. Fixed most but not all
Enabled test for timeout as well
Remaining work (
18 matches
Mail list logo
