[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GSoC 2017] Number fo sockets

From: Joan Lledó
Subject: Re: [GSoC 2017] Number fo sockets
Date: Wed, 23 Aug 2017 16:16:45 +0200

> 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.)

Those issues are not a problem for lwip.

They are using the 2-clause BSD license, is OK to apply the patch with
that license?

Thanks again.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]