Date: Sun, 22 May 2016 23:18:00 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 209558] [request] Wakeup only one thread while kqueue events are available Message-ID: <bug-209558-16-CJeYgqMXxG@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-209558-16@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-209558-16-CJeYgqMXxG>