Comment 4 for bug 379452

On Wed, May 27, 2009 at 07:22, Yann Leboulanger<email address hidden> wrote:
> Lennart Poettering wrote:
>> On Fri, 22.05.09 18:27, Damien Thébault (<email address hidden>) wrote:
>>
>>> On Fri, May 22, 2009 at 18:16, Damien Thébault
>>> <email address hidden> wrote:
>>>> That's right, it happens with the attached simple C code too, which is equivalent to the given python code.
>>>> So the problem is in the underlying libasyncns library.
>>>>
>>>> ** Attachment added: "asyncns-0.7-load.c"
>>>>   http://launchpadlibrarian.net/27057398/asyncns-0.7-load.c
>>>>
>>>>
>>>> Status in Python bindings for libasyncns: New
>>>>
>>>> Bug description:
>>>> Load goes high (4) when using this module. To reproduce, just open a python console, and type:
>>>>>>> import libasyncns
>>>>>>> asyncns = libasyncns.Asyncns()
>>>> Now in another console look at your load increasing.
>>>>
>>> CC'ing libasyncns' author Lennart Poettering about this bug.
>>> Lennart, what do you think about this?
>>
>> Hmm, no clue.
>>
>> If you can get me a simple test use case using just the C API I'd be
>> happy to take a closer look!
>>
>> Lennart

Look like recv() shouldn't be called from multiple threads on the same socket.
(See the attached file for a similar behaviour.)

If I understand it, some worker threads are created, and they wait a message
with recv() on the same fd.
Then, when a new request comes, send() is used on the connected socket,
and is picked by one of the worker threads.

Maybe a worker thread system could be implemented with queues
and pthread mutexes/conds, but it's less generic (harder to be compatible with
process workers).
Another way may be to use pipe() and select()?

The strange thing is that the same load increases with the fork() method too,
but I didn't looked at this part.

Regards,
--
Damien Thebault