We don't have to worry about synchronization here because
wine_ntoskrnl_main_loop() is only ever called from one thread per winedevice
process.

This lets drivers like mountmgr finally work, and so winecfg can open the
Drives tab.

This, or something like this, should go upstream. This is invalid behaviour.

I originally had this return STATUS_USER_APC, but that isn't correct. The
server code here is a bit confusing, but only the thread that waits *during*
the suspend should receive STATUS_USER_APC (and I imagine that it really
should receive STATUS_KERNEL_APC instead). The thread that is suspended
should just keep on waiting.

Besides, we could be suspended for reasons other than to deliver a system
APC.

Some server calls pass an event handle, most notably asyncs. We need to be
able to handle these correctly. Accordingly we pass them along to esync if
it turns out the underlying object is actually an esync object.

In an ideal world we'd just convert all instances of events on the server
side to use esyncs instead. But we want to keep esync perfectly configurable,
so this is how we do it.

We still need this, since there are some events which the server signals.

This lets system processes shut down.

The code here is sort of self-explanatory, but since I split it up over
several patches I'll provide a quick explanation. The basic principle is
that we can create an eventfd descriptor for any synchronizable handle, and
signal it on the server side whenever a wakeup would be triggered. This means
not only that we can wait simultaneously on esync primitives and on other
primitives, but that we can do it all in "user-mode", i.e. without having to
make a server call.

With this patch we break waiting on svcctl.exe.

Split off to decrease patch size.

We use ppoll() instead of poll() for the better time granularity.

Although perhaps we shouldn't since the server doesn't do this.

When a thread is terminated violently (such as by using TerminateThread)
that is not the current thread, the server sends a signal to the thread to
terminate it, but it immediately wakes up anything waiting on it. The caller
can expect WaitForSingleObject (or similar) to return when the thread is
really gone and doesn't execute anything anymore, and this is exactly what
happens on Windows.

If that thread was altering global state, and the thread that was waiting
on it will read (or alter) the global state *after* waiting for it and
expecting it to not change (because it assumes the thread is terminated by
that point, as on Windows), the result will be a race condition, since there's
no guarantee currently that the terminated thread really stopped executing.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

Changes by Sebastian Lackner <sebastian@fds-team.de>:
* Move scheduler related logic into a separate file.
* Use SCHED_RESET_ON_FORK to avoid leaking high priority threads.
* Simplify logic to parse environment variables using a helper function.
* Clean up error messages.

Changes in v2:
* accept_hardware_message should also reset ignore_post_msg.

Changes in v3:
* Fix remaining todo_wine.

These need to be merged into the patches above.

Signed-off-by: Erich E. Hoover <erich.e.hoover@gmail.com>

Signed-off-by: Erich E. Hoover <erich.e.hoover@gmail.com>

Signed-off-by: Erich E. Hoover <erich.e.hoover@gmail.com>