Joan Lledó <joanlluisll...@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.)
