Re: [Libevent-users] Asynchronous writes in the event loop model

[Frank Schoep <frank@xxxxxxx>]

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 majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.