[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-threads
Subject:    [Bug 209558] [request] Wakeup only one thread while kqueue events are available
From:       bugzilla-noreply () freebsd ! org
Date:       2016-05-22 23:18:00
Message-ID: bug-209558-16-CJeYgqMXxG () https ! bugs ! freebsd ! org/bugzilla/
[Download RAW message or body]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209558

Andy Chen <andy.yx.chen@outlook.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|Works As Intended           |---
             Status|Closed                      |Open
                 CC|                            |andy.yx.chen@outlook.com

--- Comment #5 from Andy Chen <andy.yx.chen@outlook.com> ---
(In reply to Konstantin Belousov from comment #4)
Though this has been closed, I still have two cents about this (so to make it
as active again),
1. the good stuff for kqueue is it could be used to served almost all sorts of
events, like file access, timer, socket etc. that leads to a very common design
that having a kqueue event based asynchronous event processing framework, like
libuv, as well as nginx event module. For FreeBSD, in order to implement this,
most likely that people would do is having a kqueue to hold all handles and one
thread (because of this issue) to poll events from event queue, then, since
most of the servers would not just have one CPU core, in order to leverage all
CPU resources, the framework may have a thread pool (size == # of CPUs), then
the polling thread needs to do event dispatching to thread pool, which works
fine, however, a little bit odd, comparing to how Windows IOCP does and linux's
EPOLL, in which all threads in thread pool keep reading from IOCP (or EPOLL,
http://lxr.free-electrons.com/source/include/linux/wait.h#L230), and process
any events that are available (no job re-dispatching required)

2. echoing to the point of "thread exits before event has been processed", even
you wake up all threads, all of them may also die before reach kqueue, which is
not a good reason to keep this behavior. moreover, we can make a kernel to be
robust, say, impossible to be crashed by usermode's fault, but it sounds 
impossible to me that the kernel can take care of usermode's errors, all the
kernel needs to guarantee is ensure the system is still good even there are
tens of thousands of errors in usermode.

3. moreover, having a thread to handle a socket is good, however, for many
cases, server applications would serve hundreds of connections in one second,
which doesn't means we need to create hundreds of threads for an application,
and even worse that might causes unbalanced CPU load, such as two cores, with
three requests, in async mode, it's very likely that core #1 takes req 1 and 3,
while core #2 takes req 2, while req 1 is very heavy, while req #2 is
lightweight, then request #3 may get stuck (because of core #1 is busy on req
1, though req 2 has already finished by core #2)

I believe many async IO applications/frameworks are having a very different way
for kqueue because of this (my point #1) such as asio c++ library
http://think-async.com/

Async IO is extreme important for today's server applications, which also have
a very strong requirement not to create too many threads (#of threads == #of
cpu cores), having this fix would help many developers to write asyc io
applications/frameworks in the same way as windows and linux, which I think is
valuable

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-threads@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-threads
To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]