5 ms·

So, the kernel is free to assign a connection to a new thread even if there is a previous thread working on it? Because the kernel has no idea when the previous

So, the kernel is free to assign a connection to a new thread even if there is a previous thread working on it? Because the kernel has no idea when the previous worker will be done processing the data. So the user has to manually unregister and register the connection each time? How about a concept like "transaction"? Maybe such as `epoll_begin` and `epoll_end`? One thread achieves exclusive access when entering the block, and releases it when leaving. Does this flaw also exist in IOCP or kqueue?

Philipp__ 10y ago
I think not, this[0] could be nice read. [0] http://people.eecs.berkeley.edu/~sangjin/2012/12/21/epoll-vs-kqueue.html http://people.eecs.berkeley.edu/~sangjin/2012/12/21/epoll-vs...
- yokohummer7 10y ago
  Well, just by looking at a glance, kqueue seems to pose similar problems. I mean, the problem mentioned in the OP: 1. Kernel receives some data, and wakes up A 2. A reads some data 3. Kernel receives some other data, and wakes up B (cause A didn't call `epoll_wait` yet) 4. B reads some data, leading to a race condition (out-of-order reading). kqueue's `kevent` seems to be more or less similar to `epoll_wait`, in that it doesn't seem to provide a way to notify the kernel the "we're done" signal. Am I missing here? Does `kevent` also signal the end of the exclusive access?
  - Philipp__ 10y ago
    From Bryan's interview it's clear they've solved the problem like that. From article I linked, it doesn't indicate so. Take a look here[1], at 'EVFILT_SIGNAL'. But does that mean that we have to manually attach signal to monitor, and then we receive "we're done". But that's kinda similar to what you have to do with epoll, the difference is that kqueue structure encapsulates functiona of 'epoll_wait' and 'epoll_ctl'? [1] https://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2 https://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2 Edit: sorry for spamming with links, but I find these things really interesting, look here http://austingwalters.com/io-multiplexing/ http://austingwalters.com/io-multiplexing/ specifically at 4 steps after kqueue code, I think that explains well. So it looks like we wait for signal 'done' after which we rewatch.

Philipp__ 10y ago

I think not, this[0] could be nice read. [0] http://people.eecs.berkeley.edu/~sangjin/2012/12/21/epoll-vs-kqueue.html http://people.eecs.berkeley.edu/~sangjin/2012/12/21/epoll-vs...

yokohummer7 10y ago
Well, just by looking at a glance, kqueue seems to pose similar problems. I mean, the problem mentioned in the OP: 1. Kernel receives some data, and wakes up A 2. A reads some data 3. Kernel receives some other data, and wakes up B (cause A didn't call `epoll_wait` yet) 4. B reads some data, leading to a race condition (out-of-order reading). kqueue's `kevent` seems to be more or less similar to `epoll_wait`, in that it doesn't seem to provide a way to notify the kernel the "we're done" signal. Am I missing here? Does `kevent` also signal the end of the exclusive access?
- Philipp__ 10y ago
  From Bryan's interview it's clear they've solved the problem like that. From article I linked, it doesn't indicate so. Take a look here[1], at 'EVFILT_SIGNAL'. But does that mean that we have to manually attach signal to monitor, and then we receive "we're done". But that's kinda similar to what you have to do with epoll, the difference is that kqueue structure encapsulates functiona of 'epoll_wait' and 'epoll_ctl'? [1] https://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2 https://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2 Edit: sorry for spamming with links, but I find these things really interesting, look here http://austingwalters.com/io-multiplexing/ http://austingwalters.com/io-multiplexing/ specifically at 4 steps after kqueue code, I think that explains well. So it looks like we wait for signal 'done' after which we rewatch.