Re: [GSoC 2017] Number fo sockets

[Kalle Olavi Niemitalo]

Joan Lledó <joanlluislledo@gmail.com> writes:

> I've got a question about your patch. Why did you say io_select
> without a thread per socket would require a
> different solution? I'm studying the patch b/c I'd like to send it to
> lwip maintainers, and don't find the problem.

I meant the S_io_select and S_io_select_timeout functions should
be able to return without replying to the RPC, if the socket is
not immediately ready.  They would instead put the RPC in a
queue, and if the socket later becomes ready, another thread
would remove the RPC from the queue and reply to it.  That way,
the translator would not need so many threads, saving some
memory.  This scheme seems difficult to implement using
lwip_select or lwip_poll because those functions block the
calling thread until the desired event occurs.  Instead, it
should be built on top of the lower-level lwIP functions.
It would also benefit from changes in GNU MIG.

However, I see the current pfinet already uses a thread per
io_select, so your lwIP port is not worse in this respect.

S_socket_recv (or S_io_read) has a similar issue but it is less
serious there because one application thread calling recv causes
only one translator thread to block.  (AFAIK, glibc does not have
a Hurd-specific version of lio_listio, which could start multiple
asynchronous operations with one call and thus cause multiple
threads to block in various translator processes.)