Sujet : Re: Python recompile
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.cDate : 10. Mar 2025, 22:55:07
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20250310144539.321@kylheku.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
User-Agent : slrn/pre1.0.4-9 (Linux)
On 2025-03-10, Chris M. Thomasson <
chris.m.thomasson.1@gmail.com> wrote:
On 3/10/2025 2:36 PM, Lawrence D'Oliveiro wrote:
On Mon, 10 Mar 2025 15:20:00 +0200, Michael S wrote:
Similar to poll(), yes. Not so similar to super-ugly select(). I
hope that Unix people stopped using select in new programs two or
more decades ago.
Seems like WaitForMultipleObjects is more similar to select() than
poll(), though: it has a fixed limit (MAXIMUM_WAIT_OBJECTS) on the
number of objects you can wait on at once.
But WaitForMultipleObjects can do things that poll can not, like
waiting on semaphore or on event or on thread (for completion, which
POSIX people, in their eternal fondness for idiotic names call
'join').
>
[...]
>
For some damn reason I am remembering that the array that
WaitForMultipleObjects waits on should be "shifted" or even randomized
per call in a server loop that is using EVENTS. IIRC, this was way back
in late 90's and early 2000's.
You remember correctly. I remember coding this.
The problem is that the function has no way to indicate which individual
objects are signaled, when used with the "or" semantics (any one object
being signaled can wake it up).
The function cannot indicate to the caller anything like:
you successfully acquired mutexes [3] and [4], and were
signaled by event [7].
It identifies a single object that was signaled, in spite of
the "Multiple" in its name.
When multiple objects are in some signaled state (e.g. unlocked
mutexes), the function favors the leftmost ones in the array,
leading to starvation problems in event dispatch.
The application must permute the array in order to ensure
fairness in servicing all the objects.
The current documentation still notes that:
When bWaitAll is FALSE, this function checks the handles in the array
in order starting with index 0, until one of the objects is signaled.
If multiple objects become signaled, the function returns the index of
the first handle in the array whose object was signaled.
Amazingly, it still doesn't caution the programmer against the
issue this can cause and the doesn't recommend permuting the array.
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca