On 19 jan 2012, at 21:53, Nick Mathewson wrote: > … > The usual way is with events that you manually activate. You'll need > to use libevent 2 for threading support, and call one of the > appropriate functions at startup time to turn on threading support.
I've been thinking about this over the past days and I wondered – how do POSIX signal callbacks behave under multithreaded conditions? Could I add a signal callback to the libevent loop running on one thread and have another thread raise that signal, invoking the callback on the other thread? Do I still need to use threading support in that case, or will the raised signal always properly register in a 'vanilla' libevent loop? Has anyone ever tried this? My (naive) assumption is that, since signals work at the process level, any of its pthreads will potentially become aware of a signal shortly after it is raised, because the process-to-pthread(s) mapping would act as an improvised mutex at the OS/scheduler level. Does that assumption make any sense, is it in use already by existing applications? Do Windows threads, using _beginthreadex, behave differently (like almost everything on Windows) compared to UNIX-like systems? Should I file for a software patent (j/k) or throw this idea in the trash bin? I'm sorry if I seem to be overengineering my application's design at the moment, but I really want to try to keep all inner loops lock free to maximize throughput. Although pthread mutex locking is fairly fast, skipping it altogether would be even faster, I think. With kind regards, Frank *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
