Messages in this thread | | | From | kuznet@ms2 ... | Subject | Re: Changes in the sockets: SIGIO handling | Date | Thu, 2 Mar 2000 21:12:06 +0300 (MSK) |
| |
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/
| |