[Barrelfish-users] Threads using sockets may block

[Stefan Kästle]

Hi Zaheer,

can you make sure (e.g. putting a printf) that it actually gets stuck in 
recv?

As discussed some days ago, there might be a problem with the default 
waitset if used from several threads in the same domain. Is this correct 
or do I mix up something? In that case you/we would have to find a 
workaround to pass the waitset to be used as an argument to recv.

Cheers,
  Stefan

On 02/13/2013 07:39 AM, Pravin wrote:
> Hi Zaheer,
>
> If I remember correctly, socket API was tested only with single
> threaded applications. So, there might be some issue there which we
> haven't looked at.
>
> I can take a look into it next week when I am back.  In meanwhile you
> can check that if sockets work for single threaded apps, and you might
> want to consider to use single thread till then.
>
> [[Sorry if there are multiple copies of this email]]
>
> --
> Pravin
>
> On Mon, Feb 11, 2013 at 9:14 PM, Chothia  Zaheer
> <zchothia at student.ethz.ch> wrote:
>> Hello,
>>
>> When multiple threads use the sockets API some calls may block indefinitely.
>> It seems this is because they use the default waitset -> lib/posixcompat/sockets.c:
>>
>>    ssize_t recv(int sockfd, void *buf, size_t len, int flags)
>>                      // XXX: Assume it was on the default waitset
>>                      err = us->u.active.binding->change_waitset
>>                          (us->u.active.binding, get_default_waitset());
>>
>> A simple server-client example is attached.  Output looks like this:
>>
>>    fish> /sockets both
>>    spawnd.0: spawning /sockets on core 0
>>    LWIP: in lwip_init
>>    #### sockets Going ahead with default wait-set
>>    LWIP: done with sanity check
>>    idc_c_port_mng_srv: trying to [e1000_PORTS_MNG]
>>    idc_c_port_mng_srv: success [e1000_PORTS_MNG]
>>    idc_c_ARP_lookup_srv: trying to [e1000_ARP]
>>    idc_c_ARP_lookup_srv: success [e1000_ARP]
>>    LWIP: done with connection setup
>>    #### [0:7:sockets] [BIG] [0] MEM_SIZE[62914560], PBUF_POOL_SIZE[16384], RECEIVE_BUFFERS[2044] qid[0]####
>>    Created shared_pool of size(Req 131008, Actual 131072) with role [0] and slots [2044]
>>    Allocating 2044 pbufs
>>    Mapped shared_pool of size(R 131008, A 131072) with role [0], slots[2044] and pool len[2044]
>>    [0] new_buffer_id: buffer_id = 3
>>    Created shared_pool of size(Req 131008, Actual 131072) with role [1] and slots [2044]
>>    Mapped shared_pool of size(R 131008, A 131072) with role [1], slots[2044] and pool len[2044]
>>    [0] new_buffer_id: buffer_id = 4
>>    LWIP: getting IP from ARP service
>>    ####### get IP info called ######
>>    client: owner has the IP address 10.110.4.21
>>    [server] listening on port 5000.
>>    [client] created socket: fd = 4
>>    [client] connecting to server at 10.110.4.21:5000 ...
>>    [client] connected to server at 10.110.4.21:5000
>>    [client] calling read on socket
>>    netconn_recv called on [0x805d93d8]
>>
>> The client's read call hangs and the server cannot accept or write its response.
>>
>> Is there some simple approach to remedy this issue?
>>
>> Regards,
>>
>> --Zaheer
>>
>>
>> _______________________________________________
>> Barrelfish-users mailing list
>> Barrelfish-users at lists.inf.ethz.ch
>> https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users
>>
> _______________________________________________
> Barrelfish-users mailing list
> Barrelfish-users at lists.inf.ethz.ch
> https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users

-- 
Stefan