[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GSoC 2017] Number fo sockets
From: |
Kalle Olavi Niemitalo |
Subject: |
Re: [GSoC 2017] Number fo sockets |
Date: |
Sat, 12 Aug 2017 19:24:06 +0300 |
User-agent: |
Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.51 (gnu/linux) |
Joan Lledó <joanlluislledo@gmail.com> writes:
> Since Glibc calls the io_select() operation each time the user
> calls send() or recv(), in practice such sockets are just
> unusable.
Too bad there is no lwip_poll function.
Might the LwIP folks be amenable to adding one?
> [3]
> https://github.com/jlledom/lwip-hurd/commit/ad7bf3a9342c9e75e042ce1040797392b98d24df
Your size calculations seem wrong.
glibc defines fd_mask = __fd_mask = long int.
FD_SETSIZE is the number of bits that fit in fd_set.
But then lwip_selscan does
size_t setsize = ((maxfdp1 / (8*(int)sizeof(fd_mask))) + 1) > FD_SETSIZE ?
((maxfdp1 / (8*(int)sizeof(fd_mask))) + 1) : FD_SETSIZE;
fd_mask lreadset[setsize], lwriteset[setsize], lexceptset[setsize];
[...]
memset(&lreadset, 0, setsize);
which has two bugs:
* It treats FD_SETSIZE as the minimum number of fd_mask elements,
even though it was supposed to be the number of bits.
That seems to waste some memory, but it isn't serious.
* It clears only the first setsize bytes of each array.
It should be doing memset(&lreadset, 0, setsize * sizeof(fd_mask)).
Likewise in the memcpy calls later.
This seems likely to cause real problems.
lwip_io_select_common has similar bugs plus it seems to leak
lreadset, lwriteset, or lexceptset in some cases.
I wonder how hard it would be to implement those select ops in
the translator without hogging a thread for each.
Re: [GSoC 2017] Number fo sockets, Kalle Olavi Niemitalo, 2017/08/13