Eventmachine talk - Jan 2008 - How do I detect if the event loop is running?

If I hadn''t bumped into this use-case myself, I would never have
thought it necessary to have an EventMachine::running? method...

As far as I can tell, there is no way to detect if the event loop is
already running.  Is that correct?

I''ve written a number of unit tests for my application, and part of
the sequence of things is that I start and stop the event loop
numerous times.  Somewhere along the way, my tests are goofing up,
and I end up with the following (C++?) error message:
> terminate called after throwing an instance of
''std::runtime_error''
>   what():  already initialized
> Abort trap
I would like to put a guard around the code that calls
EventMachine::run {} so that I can stop the event loop (since it
appears to be running even though it shouldn''t be) and raise my own
error message for the test case.

Any suggestions?

Thanks,
Duane Johnson

It exists: EM::reactor_running? If not, update your version of EM.

Jason

On Jan 24, 2008 6:20 PM, Duane Johnson <canadaduane at gmail.com> wrote:
> If I hadn''t bumped into this use-case myself, I would never have
> thought it necessary to have an EventMachine::running? method...
>
> As far as I can tell, there is no way to detect if the event loop is
> already running.  Is that correct?
>
> I''ve written a number of unit tests for my application, and part
of
> the sequence of things is that I start and stop the event loop
> numerous times.  Somewhere along the way, my tests are goofing up,
> and I end up with the following (C++?) error message:
>
> > terminate called after throwing an instance of
''std::runtime_error''
> >   what():  already initialized
> > Abort trap
>
> I would like to put a guard around the code that calls
> EventMachine::run {} so that I can stop the event loop (since it
> appears to be running even though it shouldn''t be) and raise my
own
> error message for the test case.
>
> Any suggestions?
>
> Thanks,
> Duane Johnson
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080124/ecb2b4f9/attachment.html

I believe that 0.9.0 was when that method was introduced.  Part of why I
built my own 0.9.0 binary for windows.

DaveS

On Jan 24, 2008 6:35 PM, Jason Roelofs <jameskilton at gmail.com> wrote:
> It exists: EM::reactor_running? If not, update your version of EM.
>
> Jason
>
>
> On Jan 24, 2008 6:20 PM, Duane Johnson <canadaduane at gmail.com>
wrote:
>
> > If I hadn''t bumped into this use-case myself, I would never
have
> > thought it necessary to have an EventMachine::running? method...
> >
> > As far as I can tell, there is no way to detect if the event loop is
> > already running.  Is that correct?
> >
> > I''ve written a number of unit tests for my application, and
part of
> > the sequence of things is that I start and stop the event loop
> > numerous times.  Somewhere along the way, my tests are goofing up,
> > and I end up with the following (C++?) error message:
> >
> > > terminate called after throwing an instance of
''std::runtime_error''
> > >   what():  already initialized
> > > Abort trap
> >
> > I would like to put a guard around the code that calls
> > EventMachine::run {} so that I can stop the event loop (since it
> > appears to be running even though it shouldn''t be) and raise
my own
> > error message for the test case.
> >
> > Any suggestions?
> >
> > Thanks,
> > Duane Johnson
> > _______________________________________________
> > Eventmachine-talk mailing list
> > Eventmachine-talk at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/eventmachine-talk
> >
>
>
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080126/cb37da8a/attachment.html

Thanks, that''s what I was looking for.  Now to debug
whatever''s
causing the std::runtime_error.

Duane

On Jan 26, 2008, at 11:07 AM, Dave Skidmore wrote:
> I believe that 0.9.0 was when that method was introduced.  Part of
> why I built my own 0.9.0 binary for windows.
>
> DaveS
>
> On Jan 24, 2008 6:35 PM, Jason Roelofs <jameskilton at gmail.com>
wrote:
> It exists: EM::reactor_running? If not, update your version of EM.
>
> Jason
>
>
> On Jan 24, 2008 6:20 PM, Duane Johnson <canadaduane at gmail.com>
wrote:
> If I hadn''t bumped into this use-case myself, I would never have
> thought it necessary to have an EventMachine::running? method...
>
> As far as I can tell, there is no way to detect if the event loop is
> already running.  Is that correct?
>
> I''ve written a number of unit tests for my application, and part
of
> the sequence of things is that I start and stop the event loop
> numerous times.  Somewhere along the way, my tests are goofing up,
> and I end up with the following (C++?) error message:
>
> > terminate called after throwing an instance of
''std::runtime_error''
> >   what():  already initialized
> > Abort trap
>
> I would like to put a guard around the code that calls
> EventMachine::run {} so that I can stop the event loop (since it
> appears to be running even though it shouldn''t be) and raise my
own
> error message for the test case.
>
> Any suggestions?
>
> Thanks,
> Duane Johnson
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>
>
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080129/a8eb8801/attachment.html

On Jan 29, 2008 10:55 PM, Duane Johnson <canadaduane at gmail.com> wrote:
> Thanks, that''s what I was looking for.  Now to debug
whatever''s causing
> the std::runtime_error.
>
>
There is a small number of conditions that can cause the reactor core to
throw a C++ exception. Things like failures to allocate memory and the like.
Not very likely.

But look for a garden-variety Ruby error being thrown out of one of your
handlers. I think something regressed recently in how EM deals with
user-generated Ruby errors.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080129/2fddeefe/attachment-0001.html

Ok Francis.  Here it is.  Indeed you are right about it being an edge
case!  The following conditions must be met:

1. An undefined method must be called inside #unbind
2. EM must start twice
3. RSpec must be involved (?)

Finding this information has taken nearly two work days... please use
it well!  :)  I''ve included a <1 kb file attachment that replicates
the std::runtime_error described.

Regards,
Duane Johnson

On Jan 29, 2008, at 9:18 PM, Francis Cianfrocca wrote:
> On Jan 29, 2008 10:55 PM, Duane Johnson <canadaduane at gmail.com>
wrote:
> Thanks, that''s what I was looking for.  Now to debug
whatever''s
> causing the std::runtime_error.
>
>
>
> There is a small number of conditions that can cause the reactor
> core to throw a C++ exception. Things like failures to allocate
> memory and the like. Not very likely.
>
> But look for a garden-variety Ruby error being thrown out of one of
> your handlers. I think something regressed recently in how EM deals
> with user-generated Ruby errors.
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080131/f1c6b0a6/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_em_exception.rb
Type: text/x-ruby-script
Size: 644 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080131/f1c6b0a6/attachment.bin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080131/f1c6b0a6/attachment-0001.html

On Jan 31, 2008 5:07 PM, Duane Johnson <canadaduane at gmail.com> wrote:
> Ok Francis.  Here it is.  Indeed you are right about it being an edge
> case!  The following conditions must be met:
>
> 1. An undefined method must be called inside #unbind
> 2. EM must start twice
> 3. RSpec must be involved (?)
>
>
>From your code sample it looks like your buggy unbind method is being called
inside of a call to EM#stop. That''s exactly the kind of case where
I''ve seen
this problem come up. What happens is that the destructor of a C++ object
gets called recursively inside of itself. I''ll work on getting your
code to
show the error and hopefully fix it asap.

Thanks for putting the time in on this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080201/a320fd8d/attachment.html

On Jan 31, 2008 5:07 PM, Duane Johnson <canadaduane at gmail.com> wrote:
> Ok Francis.  Here it is.  Indeed you are right about it being an edge
> case!  The following conditions must be met:
>
> 1. An undefined method must be called inside #unbind
> 2. EM must start twice
> 3. RSpec must be involved (?)
>
> Finding this information has taken nearly two work days... please use it
> well!  :)  I''ve included a <1 kb file attachment that
replicates the
> std::runtime_error described.
>
>

I found the problem.

If you call EM#stop,  the reactor will run down all open descriptors and
send the unbind event to each one. If a Ruby exception occurs inside an
#unbind method, the rest of the the EM#stop call gets short-circuited. (This
is the bug.) When you then call EM#run a second time, you get a C++
exception because the reactor didn''t get properly released from the
prior
EM#run call.

The fix is easy, but I''m going to hold it for a little while because I
might
think of a better way to fix it.

Thanks again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080201/6847632a/attachment.html

On Feb 1, 2008, at 3:45 AM, Francis Cianfrocca wrote:
> On Jan 31, 2008 5:07 PM, Duane Johnson <canadaduane at gmail.com>
wrote:
> Ok Francis.  Here it is.  Indeed you are right about it being an
> edge case!  The following conditions must be met:
>
> 1. An undefined method must be called inside #unbind
> 2. EM must start twice
> 3. RSpec must be involved (?)
>
> Finding this information has taken nearly two work days... please
> use it well!  :)  I''ve included a <1 kb file attachment that
> replicates the std::runtime_error described.
>
>
>
> I found the problem.
>
> If you call EM#stop,  the reactor will run down all open
> descriptors and send the unbind event to each one. If a Ruby
> exception occurs inside an #unbind method, the rest of the the
> EM#stop call gets short-circuited. (This is the bug.) When you then
> call EM#run a second time, you get a C++ exception because the
> reactor didn''t get properly released from the prior EM#run call.
>
> The fix is easy, but I''m going to hold it for a little while
> because I might think of a better way to fix it.
>
> Thanks again.
Fantastic!  Thanks for taking a look into this.  I don''t think
I''ll
get bitten by it again, but for the sake of others'' sanity,
I''m sure
your fix will be appreciated :)

Regards,
Duane

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080201/533fe1c2/attachment-0001.html

>
> Fantastic!  Thanks for taking a look into this.  I don''t think
I''ll get
> bitten by it again, but for the sake of others'' sanity,
I''m sure your fix
> will be appreciated :)
>
>
The amount of time I put into it was trivial compared to what you did.

And by the way, the problem was indeed dependent on Rspec, although
it''s a
mystery to me why that should be the case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20080201/2e39694f/attachment.html