Hello!
> Here is a list of proposed changes in the SIGIO handling for
> sockets.
I see several evident small holes in the patch, which make it inacceptable.
1.
+ /* We want to modify the accepted socket, so check accept_flags */
+ if (newsock->sk->accept_flags)
+ check_accept_flags(err, sock, newsock);
It cannot work. Please, read comment above sock_map_fd().
2. sk->state_change() cannot be replaced with sk->data_ready()
even when it sends plain POLL_IN. They are different.
I did this mistake once and had to return them back. 8)
3. Patch is not formatted, which shows that you did not look at it.
Also, //. 8)8)
4. POLL_HUP cannot be used as barrier for file close. It is _evident_,
that it has no relation to the recent discussion in the list.
If you follow the discussion, you send rather POLLNVAL event. See?
And not from network but from the point where file _descriptor_ is
invalidated. So, new signal sources are simply in wrong place and
wrongly named.
Besides that, please, make sure that such events are _not_ sent
with not-rt signals, when signals are not queued. I see, you forgot
that signal is more expensive than syscall, it was the reason
why old signals aggresively compressed events.
> - Don't return POLL_HUP at EOF, return POLL_IN instead.
POLL_HUP had well-defined semantics. Please, do not break it,
if it is possible.
> - add SO_ACCEPT_FLAGS socket option.
I would prefer acceptx() syscall, which will make this and
receive the first chunk of data on demand.
But generally I suspect SO_ACCEPT_FLAGS is a broken idea.
You work with VFS object, but control it from socket layer.
You forgot about dup*(), by the way.
> We want to reduce the number of syscalls.
Instead, you drastically increase number of signals, which
are much more expensive, than syscalls. Are you really sure
that it is right way? 8)8)8) I see, the patch consists of two
independant parts: accept() extension looks OK (provided
it is made correctly) and close tracking. Close tracking
is fully broken, it must be hooked to VFS in the places, where
descriptor is invalidated.
> Are there any plans SIGIO to be supported for AF_UNIX?
Khm... Is it really not supported?
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:12 EST