Doccumetation issue: "The Service Thread" Does it exist?
This concerns the documentation on thw www.winehq.com website, if it's out of date, then this post may be irrelevant. In the "Wine Developer's Guide" In Section 8.1.4, "The Service thread" Says there exists a service thread, that is implemented in: scheduler/services.c. It also says this thread is used to support the X11 driver's event loop. Firstly, I cannot find the "scheduler/services.c" file. Secondly from my reading of the x11drv code, the X11 event loop is serviced for every call of to X11DRV_MsgWaitForMultipleObjectsEx, which is inturn called by MsgWaitForMultipleObjectsEx, and GetMessage. Therefore, whichever thread is active will service the X11 event queue. It also appears, because each thread has it's own XDisplay object that messages created by a X11 window will only be picked up in the thread that created the window. Am I correct, or have I missed something fundamental? Bye -Rob.
Robert North a écrit:
This concerns the documentation on thw www.winehq.com website, if it's out of date, then this post may be irrelevant.
In the "Wine Developer's Guide" In Section 8.1.4, "The Service thread"
Says there exists a service thread, that is implemented in: scheduler/services.c. It also says this thread is used to support the X11 driver's event loop.
Firstly, I cannot find the "scheduler/services.c" file.
Secondly from my reading of the x11drv code, the X11 event loop is serviced for every call of to X11DRV_MsgWaitForMultipleObjectsEx, which is inturn called by MsgWaitForMultipleObjectsEx, and GetMessage. Therefore, whichever thread is active will service the X11 event queue.
It also appears, because each thread has it's own XDisplay object that messages created by a X11 window will only be picked up in the thread that created the window.
Am I correct, or have I missed something fundamental?
Bye -Rob.
From http://cvs.winehq.org/cvsweb/wine/scheduler/Attic/services.c: Revision 1.14 FILE REMOVED Removed service thread support. Guess it answer why you can't find scheduler/services.c. Somebody else than me can probably tell you why, or what replaced it. Vincent
Vincent Béron vberon-at-mecano.gme.usherb.ca |Wine Mailing Lists| wrote:
Robert North a écrit:
This concerns the documentation on thw www.winehq.com website, if it's out of date, then this post may be irrelevant.
In the "Wine Developer's Guide" In Section 8.1.4, "The Service thread"
Says there exists a service thread, that is implemented in: scheduler/services.c. It also says this thread is used to support the X11 driver's event loop.
Firstly, I cannot find the "scheduler/services.c" file.
[Snip irrelevant stuff]
From http://cvs.winehq.org/cvsweb/wine/scheduler/Attic/services.c: Revision 1.14 FILE REMOVED Removed service thread support.
Guess it answer why you can't find scheduler/services.c.
Somebody else than me can probably tell you why, or what replaced it.
Vincent
Now why didn't I think of doing a CVS search ;-) Did a google on the winehq site, and found that Alexandre wanted to remove it, but not why. I'll just have to wait for further replies. Thanks -Rob.
On Thu, 23 Jan 2003, Robert North wrote:
This concerns the documentation on thw www.winehq.com website, if it's out of date, then this post may be irrelevant.
In the "Wine Developer's Guide" In Section 8.1.4, "The Service thread"
Says there exists a service thread, that is implemented in: scheduler/services.c. It also says this thread is used to support the X11 driver's event loop.
Firstly, I cannot find the "scheduler/services.c" file.
Yeah, the service thread is no more. Everything it did is now done more or less synchronously, in the thread that needs the functionality, instead of having another thread do it (or sometimes by shifting more functionality into the wineserver).
Secondly from my reading of the x11drv code, the X11 event loop is serviced for every call of to X11DRV_MsgWaitForMultipleObjectsEx, which is inturn called by MsgWaitForMultipleObjectsEx, and GetMessage. Therefore, whichever thread is active will service the X11 event queue.
Almost; each thread has its own display and X11 event queue now, where the messages that this thread is interested in gets posted. That way there's no need for a process-wide queue or an independent service thread to process it, instead the thread can check its own thread-specific queue whenever it's appropriate for it to do so.
It also appears, because each thread has it's own XDisplay object that messages created by a X11 window will only be picked up in the thread that created the window.
That's right. It even fits the Win32 model better, as there, messages to a window are always sent to the thread that created the window.
participants (3)
-
Ove Kaaven -
Robert North -
Vincent Béron