empty loop, adding watchers, one minute idle

Zoltán Lajos Kis zoltan.lajos.kis at gmail.com
Sun Mar 25 11:04:56 CEST 2012


Hi Marc,

Thanks for your response. I believe I have all the needed locking in place.
I distilled the problem into the attached source code. TEST=1 is the
regular case, and it works as expected.
TEST=2 starts the empty loop, and then adds the watcher few seconds later.
In this case the event is fired only sixty seconds after the loop was
started (regardless of when the watcher was started).

Is there any other calls / locking I need to use in this latter case to
have the event fire right away?

Thanks,
Zoltan.

PS: The system is Ubuntu 11.10 32-bit (3.0.0.16), and the backend used by
libev is epoll.

2012. március 20. 14:11 Marc Lehmann írta, <schmorp at schmorp.de>:

> On Mon, Mar 19, 2012 at 09:58:24PM +0100, Zoltán Lajos Kis <
> zoltan.lajos.kis at gmail.com> wrote:
> > create an io watcher for the socket, and start the socket on the started
> > loop. (note: the request processing, and watcher preparation is done on
> > another thread.)
> > get no immediate results. However, roughly after one minute (since
> starting
> > the loop?) the events show up as they were buffered, and from that time
> > packets are
>
> since you use threads, are you sure you use proper locking? from the
> symptoms, it seems you don't - in geenral, when you access a shared
> resource (such as the event loop) you need to lock it with e.g. a mutex.
>
> > What I do now is that I set up an async watcher and a message queue to
> the
> > thread. Then instead of starting the watcher, I put the watcher ('s
> > pointer) to the queue, and notify the loop about this using the async
> > watcher.
>
> Yes - but if you don't use proper locking, you will get data corruption
> under certain circumstances. If you want to access the same loop from
> different threads, you need to lock it against concurrent access - see
> thwe thread locking example in the manual for example.
>
> > My question is whether someone could explain me what is actually going
> on,
> > and what would be a cleaner solution for the problem.
>
> 1. read the documentation, if you then sitll have questions, feel free to
>   ask them.
> 2. thread programming is notoriously difficult - as a rule of thumb,
>   protecting shared resources with a mutex is a must, but there are many
> other
>   cases where you need to use special thread functions when working with
>   threads, such as using condvars, or async watchers.
>
> failure to lock will most likely seem to work under light load, but will
> lead to memory corruption unless you are extremely lucky. it will also
> cause the symptom you describe, as if you would properly lock the loop you
> would block in the lock (because the other thread is inside ev_run).
>
> --
>                The choice of a       Deliantra, the free code+content MORPG
>      -----==-     _GNU_              http://www.deliantra.net
>      ----==-- _       generation
>      ---==---(_)__  __ ____  __      Marc Lehmann
>      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
>      -=====/_/_//_/\_,_/ /_/\_\
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20120325/8eb20ede/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: evtest.c
Type: text/x-csrc
Size: 1601 bytes
Desc: not available
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20120325/8eb20ede/attachment.c>


More information about the libev mailing list