+
+There are several ways to "fix" this:
+
+in kernel (poll solution)::
+ Let the file descriptor be pollable, and let it be readable (returning
+ something like the amount of overcommit at read() time for example) so
+ that userland is notified that it should try to reduce the amount of
+ runnable threads.
++
+It sounds very easy, but it has one major drawback: it meaks the pwqfd must be
+somehow registered into the eventloop, and it's not very suitable for a
+pthread_workqueue implementation. In other words, if you can plug into the
+event-loop because it's a custom one or one that provides thread regulation
+then it's fine, if you can't (glib, libdispatch, ...) then you need a thread
+that will basically just poll() on this file-descriptor, it's really wasteful.
++
+NOTE: this has been implemented now, but still it looks "expensive" to hook
+for some users. So if some alternative way to be signalled could exist, it'd
+be really awesome.
+
+in userspace::
+ Userspace knows how many "running" threads there are, it's easy to
+ track the amount of registered threads, and parked/waiting threads are
+ already accounted for. When "waiting" is zero, if "registerd - parked"
+ is "High" userspace could choose to randomly try to park one thread.
++
+userspace can use non blocking read() to probe if it's overcommiting.
++
+It's in NONE when userspace belives it's not necessary to probe (e.g. when the
+amount of running + waiting threads isn't that large, say less than 110% of
+the concurrency or any kind of similar rule).
++
+It's in SLOW mode else. In slow mode each thread does a probe every 32 or 64
+jobs to mitigate the cost of the syscall. If the probe returns '1' then ask
+for down-commiting and stay in SLOW mode, if it returns AGAIN all is fine, if
+it returns more than '1' ask for down-commiting and go to AGGRESSIVE.
++
+When AGGRESSVE threads check if they must park more often and in a more
+controlled fashion (every 32 or 64 jobs isn't nice because jobs can be very
+long), for example based on some poor man's timer (clock_gettime(MONOTONIC)
+sounds fine). State transition works as for SLOW.
++
+The issue I have with this is that it sounds to add quite some code in the
+fastpath code, hence I dislike it a lot.
+
+my dream::
+ To be able to define a new signal we could asynchronously send to the
+ process. The signal handler would just put some global flag to '1',
+ the threads in turn would check for this flag in their job consuming
+ loop, and the first thread that sees it to '1', xchg()s 0 for it, and
+ goes to PARK mode if it got the '1'. It's fast, inexpensive.
++
+Sadly AFAICT defining new signals() isn't such a good idea. Another
+possibility is to give an address for the flag at pwqr_create() time and let
+the kernel directly write into userland. The problem is, I feel like it's a
+very wrong interface somehow. I should ask some kernel hacker to know if that
+would be really frowned upon. If not, then that's the leanest solution of all.