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/> References: <bug-209558-16@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209558 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 de= sign that having a kqueue event based asynchronous event processing framework, l= ike libuv, as well as nginx event module. For FreeBSD, in order to implement th= is, 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 =3D=3D # 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 lin= ux'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, whic= h 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=20 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 secon= d, which doesn't means we need to create hundreds of threads for an applicatio= n, and even worse that might causes unbalanced CPU load, such as two cores, wi= th three requests, in async mode, it's very likely that core #1 takes req 1 an= d 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 r= eq 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 h= ave a very strong requirement not to create too many threads (#of threads =3D= =3D #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 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-209558-16-CJeYgqMXxG>