On Mon, Feb 6, 2012 at 5:46 PM, William Ahern
wrote:
> On Mon, Feb 06, 2012 at 01:46:59PM -0800, Adrian Chadd wrote:
>> Hi,
>>
>> the standard trick:
>>
>> * designate one thread as "signals here" and block signals on all other
>> threads;
>> * use pipes for sending signals between threads (ie, t
On Mon, Feb 6, 2012 at 4:46 PM, Adrian Chadd wrote:
> Hi,
>
> the standard trick:
>
> * designate one thread as "signals here" and block signals on all other
> threads;
Actually, if we're willing to require that the user block signals on
non-"signals here" threads themself, we can do a lot bette
On 02/06/2012 04:46 PM, Adrian Chadd wrote:
Hi,
the standard trick:
* designate one thread as "signals here" and block signals on all other threads;
* use pipes for sending signals between threads (ie, to wake them up);
* wish that kqueue and similar methods were portable.
The kqueue API has
On Mon, Feb 06, 2012 at 01:46:59PM -0800, Adrian Chadd wrote:
> Hi,
>
> the standard trick:
>
> * designate one thread as "signals here" and block signals on all other
> threads;
> * use pipes for sending signals between threads (ie, to wake them up);
> * wish that kqueue and similar methods wer
Hi,
the standard trick:
* designate one thread as "signals here" and block signals on all other threads;
* use pipes for sending signals between threads (ie, to wake them up);
* wish that kqueue and similar methods were portable.
adrian
*
On 1 feb 2012, at 23:31, Nick Mathewson wrote:
> … [ questions about POSIX signals and pthreads ] …
> …
> Sadly, this whole business is a huge pile of gunk.
Thanks for the epic reply, Nick.
I did some additional research before diving into my POSIX signal plan and it
indeed looks like a huge mes
On Sun, Jan 22, 2012 at 9:44 AM, Frank Schoep wrote:
> 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 t
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 pa
On Thu, Jan 19, 2012 at 4:23 PM, Nick Mathewson wrote:
> Libevent's buffereing code is better for network connections than for
> inter-thread communication, though you ought to be able to use an
> evbuffer as your queue if that's what you really want to do.
> Personally, though, I'd just use a q
On Thu, Jan 19, 2012 at 9:23 AM, Frank Schoep wrote:
> Hello everyone,
>
> After reading the libevent documentation and hacking on some of the code
> samples, I've got a question about doing 'asynchronous' socket writes using
> the event loop model.
>
> I completely understand how libevent can b
Hello everyone,
After reading the libevent documentation and hacking on some of the code
samples, I've got a question about doing 'asynchronous' socket writes using the
event loop model.
I completely understand how libevent can be used to create an HTTP (or alike)
server, thanks to that protoc
11 matches
Mail list logo