----- Original Message ---- > From: Julian Scheel <jul...@jusst.de> > To: libevent-users@monkey.org > Sent: Tuesday, April 7, 2009 6:41:05 AM > Subject: [Libevent-users] bufferevents and multiple threads > > Hi, > > I currently see a problem of which I am not really sure what's the actual > reason, but I think it is related to multiple threads in my application. > I do use bufferevents to communicate over a http connection (not using evhttp > as I need different features - streaming actually). I create the socket and > add an event handler for actions on that socket in my main thread which > afterwards calls event_dispatch. > The actual feed in of data is done in a seperate thread though. This thread > does nothing but monitoring a ringbuffer and write data to the socket with > bufferevent_write_buffer. > Soem data is actually transmitted to the client, but it is garbled. Also > after > a while of running the app I get errors like this one: > [err] event_queue_insert: 0x9c9d724(fd 13) already on queue 2 > > > > I do only call event_init once in the main thread. So there shouldn't be > multiple event_bases existing, but maybe I still have to do something > specific > in the other threads? - Wouldn't that threads use the current_base from the > mainthread normally?
I initially made the same mistake. The problem is the other threads DO use the same current_base, but there's no thread safety built into the libevent functions such as mutex locking. Instead, the thread that's running that event_base's loop must do all of the interaction with its bufferevents. I ended up implementing an invoke-on-event-loop function handler that used a pipe to pass function pointers to be executed by the event_base's thread. I believe this was mentioned in an earlier discussion as being planned for libevent 2.0, but the implementation is pretty trivial. My other solution was to not use bufferevents where I was reasonably confident calls to write() wouldn't block and use libevent for reading only. As far as I can tell, write()/send() are thread-safe although I can't guarantee this is the case. If anyone has other suggestions about how to handle this, I'd also be interested in hearing them. > > I'd be glad if someone has an idea on this issue... > > Regards, > Julian Larry > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkeymail.org/mailman/listinfo/libevent-users _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
