On Wed, Apr 11, 2012 at 02:21:13AM +0300, Nir Soffer wrote:
> Forward jumps should simply skip events in the past. It is just like
> events skipped because the event loop was blocked.
>
> If you should run every 5 seconds, but woke up 21 seconds late, you
> cannot fix the past - you just miss
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
On Tue, Apr 10, 2012 at 6:38 PM, Myk Taylor wrote:
> On 03/26/12 01:17, Myk Taylor wrote:
>>
>> Alright, now that I understand a little more about how to do this, let
>> me try this again : )
>
>
> The updated patches are now attached to the sourceforge Patches tracker:
>
> https://sourceforge.net
On Tue, Apr 10, 2012 at 6:41 PM, Jan Danielsson
wrote:
> Hello,
>
> I'm not really clear on what EV_WRITE means for UDP. Does it
> essentially guarantee that sendto() won't return EAGAIN, ENOBUFS et al
> (backend quirks aside)?
Basically, yes.
> Assuming I'm on a pthreads platform, and I hav
On Apr 10, 2012, at 6:15 PM, Nick Mathewson wrote:
And there's a third way for libevent to see a big jump forward in
time: if the program calls event_base_loop() sporadically, it is free
to wait as long as it wants between invocations.
So, what's the right behavior for periodic events in these
Hello,
I'm not really clear on what EV_WRITE means for UDP. Does it
essentially guarantee that sendto() won't return EAGAIN, ENOBUFS et al
(backend quirks aside)?
Assuming I'm on a pthreads platform, and I have a few TCP channels
which are used for query-operations, and a query can take a w
On 03/26/12 01:17, Myk Taylor wrote:
Alright, now that I understand a little more about how to do this, let
me try this again : )
The updated patches are now attached to the sourceforge Patches tracker:
https://sourceforge.net/tracker/?func=detail&aid=3516647&group_id=50884&atid=461324
Thanks
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
On Mon, Apr 9, 2012 at 11:44 PM, 卓宜黄 wrote:
> Hi all,
>
> I found an issue that it will trigger the timer callback dramatically
> like a dead looping when moving the system time backward for a year
> and then moving it forward to the accurate time.
> Of course, I had to change the system time for
On Tue, Apr 10, 2012 at 1:03 AM, William Ahern
wrote:
> On Tue, Apr 10, 2012 at 11:44:39AM +0800, 卓宜黄 wrote:
>> Hi all,
>>
>> I found an issue that it will trigger the timer callback dramatically
>> like a dead looping when moving the system time backward for a year
>> and then moving it forward t
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
15 matches
Mail list logo
