On Tue, Apr 10, 2012 at 8:04 PM, Nir Soffer wrote:
>
> On Apr 10, 2012, at 6:33 PM, Nick Mathewson wrote:
>
> Instead you can simply say:
>
> ev = event_new(base, -1, 0, process_work_queue_cb, NULL);
> event_active(ev, EV_TIMEOUT, 1);
>
> The second approach is better because it doesn't requir
On Apr 10, 2012, at 6:33 PM, Nick Mathewson wrote:
Instead you can simply say:
ev = event_new(base, -1, 0, process_work_queue_cb, NULL);
event_active(ev, EV_TIMEOUT, 1);
The second approach is better because it doesn't require you to put
the event in the timeout heap at all: instead, Libe
Hi,
I was having similar kind of problem.
in order to resolve it, I stopped processing my commands in read callback.
I read commands in read callback and pushed them to my synchronized queue
where threads are waiting on that queue for commands to process them. This
approach reduced burden on read
On Tue, Apr 10, 2012 at 5:10 AM, Nils Rennebarth
wrote:
> Hi,
>
> In my daemon which uses libevent, i use bufferevent to read client commands
> from a socket, set everything up to eventually generate the reply, and return
> to
> the event loop.
>
> Now a client may send several commands in one go
Le 10.04.2012 11:10, Nils Rennebarth a écrit :
Or is there something like a idle task, that get called when there is
nothing else to do? Working with timeouts would introduce arbitrary
gaps
in command handling, event if there are no other clients that want
work, so I won't go that route. Or do
Hi Nils,
I have a similar use case and I am following the approach described below.
1. Determine an ideal low watermark for the read callback.
2. I'm not sure if there are any disadvantages to this approach, but you
could try to read within a loop inside the read callback till there is no
further
Hi,
In my daemon which uses libevent, i use bufferevent to read client commands
from a socket, set everything up to eventually generate the reply, and return to
the event loop.
Now a client may send several commands in one go. If I only read the first
command and drain the corresponding bytes fro
