Re: [Libevent-users] Help with progress thread

[Ralph Castain <rhc@xxxxxxxxxxxx>]

Hi Nick

Appreciate the help. Shame on me for the buglet re open.

Using your revisions, I was able to get this to work with our integration (i.e., using the opal abstractions). I'm a little puzzled by the procedure, though, so if you don't mind my tasking your patience, I do have a question.

I gather that the standard procedure in threaded scenarios is to signal the "progress thread" every time a new event is assigned to that event base by another thread. Your "event_active" method is nicer than writing a pipe - thanks for pointing it out - but bottom line is that you have to use an "update" event to force the event lib out of event_loop and then re-enter event_loop. True?

If I assign a new event in thread B, and "update" the progress thread, do I need to "update" it again when thread B later "adds" the event (I'm assuming the case where I assign a new event, but don't add/activate it until some later time)?

Just as an FYI. Your web site indicates that a lot of these questions may be addressed in an email thread from Steven Grimm. However, the referenced link is for an email in Jan 2007, and the email archives don't quite go back that far - leaving the link broken. Any chance you have the referenced example somewhere and can restore the link? It sounded like he addresses a lot of these issues.


On Nov 11, 2010, at 8:34 PM, Nick Mathewson wrote:

> On Thu, Nov 11, 2010 at 8:00 PM, Ralph Castain <rhc@xxxxxxxxxxxx> wrote:
>> Afraid I am hitting a brick wall, Nick. I can't make the threaded code work. Perhaps you have some further advice?
>> 
>> I have attached my test code. Basically, it initializes the event lib, calls use_threads, creates a new base, and then spawns a progress thread that calls event_loop (you'll see that we prepended "opal" to your calls as part of an abstraction requirement - but I believe the calls are still understandable). The call to event_init is embedded in opal_init.
>> 
> 
> Here's a revised version of your test code.  The biggest change is
> that I replaced all the opal calls with their libevent or pthread
> equivalents so that I could actually run it on my little OSX box, and
> rule out any possible bugs in the opal code.  (Not that there
> necessarily _are_ any.)  The second-biggest change I made is that I
> added error checking to all of the calls. This turned up a small bug:
> you weren't specifying the third "mode" argument to open(), which is
> required if you are using the O_CREAT flag.  For me, this resulted in
> a "foo" file which I couldn't open after the first time, which meant
> that my_fd would always be -1.
> 
> There's also a race condition in how you handle the fd_written
> variable, but in practice it shouldn't matter in most places.
> 
> I also added a demo for how to use event_active() to wake up the
> subthread, if that's something you're interested in.  Define the C
> macro WAKE_WITH_EVENT if you're interested in trying that out.
> 
> When I built the revised code and linked it against libevent master using
> 
>   gcc -Wall -pthread -levent -levent_pthreads evthread-test.c -o evthread-test
> 
> it worked fine for me.  (That is, the write event fired message
> appeared okay.)  This is on OSX 10.5.8.
> 
> If this code doesn't work for you, we'll have to start figuring out
> why I'm misinterpreting the results, or how our systems differ.  If it
> does work for you, we'll have to figure out whether your version is
> failing because of something your library is doing differently from
> straight libevent+pthreads, or because of the open() issue above, or
> what.
> 
> yrs,
> -- 
> Nick
> <evthread-test.c>

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