Comment 5 for bug 379452

Damien Thébault wrote:
> 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,
>

Will there be any attempt to fix this or is the development of this
library dead?
--
Yann Leboulanger