Am Dienstag, 7. April 2009 13:48:58 schrieb Larry Lewis: > 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. >
Ok, I changed the workflow so that instead of having a ringbuffer monitor thread for each output I now call the output function by a evtimer from the main thread. That solved the error messages. Still the data is garbled, wondering why this might happen... What I am actually doing on sending is calling evbuffer_add_printf, evbuffer_add, evbuffer_add_printf and then bufferevent_write_buffer. If I write the same data blocks to a file in parallel I can verify that the data I am heading over there is ok. Regards, Julian _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
