Re: [Libevent-users] Signals and priority queues

[Ralph Castain <rhc@xxxxxxxxxxxx>]

Afraid I'm going to have to eat my words here, Nick. It looks like something is going on in the code - not entirely sure just where yet (mine or libevent). I've installed a clean version of 2.0.13 (removing everything but the glue) into OMPI, and the problems persist. I've also tried converting to a true fd-based event using pipes, and get the identical behavior.

I'm going to spend some more time over the weekend looking at this before begging more of your time on it. I'm hoping to pin it down a little more for you, or at least provide an updated reproducer.

Thanks again
Ralph

On Jan 6, 2012, at 8:15 AM, Ralph Castain wrote:

> 
> On Jan 6, 2012, at 7:02 AM, Nick Mathewson wrote:
> 
>> On Fri, Jan 6, 2012 at 7:24 AM, Ralph Castain <rhc@xxxxxxxxxxxx> wrote:
>>> If it helps, I have now confirmed that I *can* activate the t2 event during the t1func callback in my example *provided* I called event_assign on it prior to entering event_base_loop. It is also okay for me to event_add the t2 event during the callback - I am simply not allowed to event_assign *and* activate it there.
>>> 
>>> However, it is okay to assign the event during the callback so long as I don't activate it until after I return.
>>> 
>>> Seems a little strange to me - is this the intended behavior?
>> 
>> Well, no, of course not.
>> 
>> Looking at your code, the only weird thing I see at first glance is
>> that you are calling event_add() on t1 and t2 -- you shouldn't be
>> doing that.  event_add() is only for events that you want libevent to
>> poll or wait for, but waiting for EV_WRITE on fd -1 isn't
>> well-defined.  If you want to activate them yourself with
>> event_active(), there's no need to event_add() them.
>> 
>> That shouldn't be causing this problem, though, I think.  (Unless it is?)
> 
> BINGO! Indeed, event_add was the source of the trouble. My bad for not understanding when event_add was required.
> 
>> 
>> I just tried your test programs, though, and they worked okay for me
>> on OSX and linux, using Libevent 2.0.13-stable and Libevent
>> 2.0.14-stable.
>> 
>> What platform are you running your tests on?  Have you tried other
>> platforms too?  Does the outcome depend on which libevent backend is
>> in use?  Have you tried this with an unpatched Libevent, just to
>> confirm that it's not introduced by any openmpi patches?
> 
> FWICT, it is a corruption issue, and so it does indeed depend on platform and backend - just a question of what memory location gets trounced.
> 
> FWIW, I was conducting my tests on OSX and linux as well, using OMPI with 2.0.13 underneath. I think the difference in our results is due to the location issue - I suspect that you might also hit a problem if we continued chaining events long enough, but I haven't confirmed it.
> 
> Also fwiw: the OMPI changes are confined to configuration/Makefile areas - we actually don't fiddle with the libevent code itself other than a couple of places where we test for stdbool.h before including it.
> 
> Thanks Nick!
> Ralph
> 
>> 
>> yrs,
>> -- 
>> Nick
>> ***********************************************************************
>> To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
>> unsubscribe libevent-users    in the body.
> 

***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.