f



MsgWaitForMultipleObjects - dynamically add and remove event objects

Hello All,

Well, now I've got a message loop including MsgWaitForMultipleObjects
running, I've stumbled into the next problem:

How do I *dynamically* add and remove event objects to/from its list ?

Currently I'm posting a message with a request for an event object to be
added or removed, which causes the MsgWaitForMultipleObjects to exit, after
which I, in the PeekMessage loop, capture the request and do whatever needs
to be done.


The problem with that is that its asynchronous, which creates a problem for
me when removing an event object:  After posting such a "remove" message I
cannot assume its released, and thus cannot delete it (otherwise
MsgWaitForMultipleObjects could be throwing an error indicating a faulty
event object handle).

I could ofcourse let the code which removes the event object from the array
either delete the event object or post a "Its done" message back, but
somehow I do not really like either solution.

tl;dr:
Is there a way to *synchronously* add / remove an object from a list which
is in use by a MsgWaitForMultipleObjects call.

I was thinking about adding a special event object just so I could get the
MsgWaitForMultipleObjects call to exit, but am rather unsure if that will
work and will work in a dependant way.


Argh ...   Just thought of the problem when trying to do the adding /
removing from within another thread ...   In that case that "special event
object" idea won't work. :-(

Regards,
Rudy Wieser



0
R
12/15/2016 11:55:41 AM
comp.os.programmer.win32 14523 articles. 0 followers. Post Follow

6 Replies
229 Views

Similar Articles

[PageSpeed] 44

On Thu, 15 Dec 2016 12:55:41 +0100, R.Wieser wrote:
> Hello All,
> 
> Well, now I've got a message loop including MsgWaitForMultipleObjects
> running, I've stumbled into the next problem:
> 
> How do I *dynamically* add and remove event objects to/from its list ?
> 
> Currently I'm posting a message with a request for an event object to be
> added or removed, which causes the MsgWaitForMultipleObjects to exit, after
> which I, in the PeekMessage loop, capture the request and do whatever needs
> to be done.
> 
> The problem with that is that its asynchronous, which creates a problem for
> me when removing an event object:  After posting such a "remove" message I
> cannot assume its released, and thus cannot delete it (otherwise
> MsgWaitForMultipleObjects could be throwing an error indicating a faulty
> event object handle).
> 
> I could ofcourse let the code which removes the event object from the array
> either delete the event object or post a "Its done" message back, but
> somehow I do not really like either solution.
> 
> tl;dr:
> Is there a way to *synchronously* add / remove an object from a list which
> is in use by a MsgWaitForMultipleObjects call.
> 
> I was thinking about adding a special event object just so I could get the
> MsgWaitForMultipleObjects call to exit, but am rather unsure if that will
> work and will work in a dependant way.
> 
> Argh ...   Just thought of the problem when trying to do the adding /
> removing from within another thread ...   In that case that "special event
> object" idea won't work. :-(
> 
> Regards,
> Rudy Wieser

That's yet another internal structure thinkering.

Why not simply assign the first event list slot for the
here-is-another-event-to-wait-for event? Let the second and the remaining
slots be available for events that got added and removed.
0
JJ
12/15/2016 10:02:04 PM
JJ,

> That's yet another internal structure thinkering.

Nope, this one isn't.  The MsgWaitForMultipleObjects and its arguments are
fully described.

And if you mean that I'm "tinkering" with the message loop itself ?   How do
*you* , for a PeekMessage loop, detect a WM_QUIT being posted ? :-)

> Why not simply assign the first event list slot for the
> here-is-another-event-to-wait-for event?

I already mentioned that I thought about that:

> > I was thinking about adding a special event object just so I could
> > get the MsgWaitForMultipleObjects call to exit, but am rather
> > unsure if that will work and will work in a dependant way.

which I than followed with this remark:

> > Argh ...   Just thought of the problem when trying to do the
> > adding / removing from within another thread ...   In that case
> > that "special event object" idea won't work. :-(

So no, I don't think that that will work in a generic way.

Regards,
Rudy Wieser


-- Origional message:
JJ <jj4public@vfemail.net> schreef in berichtnieuws
lfx7n38ri6w8$.grz9rims92ft$.dlg@40tude.net...
> On Thu, 15 Dec 2016 12:55:41 +0100, R.Wieser wrote:
> > Hello All,
> >
> > Well, now I've got a message loop including MsgWaitForMultipleObjects
> > running, I've stumbled into the next problem:
> >
> > How do I *dynamically* add and remove event objects to/from its list ?
> >
> > Currently I'm posting a message with a request for an event object to be
> > added or removed, which causes the MsgWaitForMultipleObjects to exit,
after
> > which I, in the PeekMessage loop, capture the request and do whatever
needs
> > to be done.
> >
> > The problem with that is that its asynchronous, which creates a problem
for
> > me when removing an event object:  After posting such a "remove" message
I
> > cannot assume its released, and thus cannot delete it (otherwise
> > MsgWaitForMultipleObjects could be throwing an error indicating a faulty
> > event object handle).
> >
> > I could ofcourse let the code which removes the event object from the
array
> > either delete the event object or post a "Its done" message back, but
> > somehow I do not really like either solution.
> >
> > tl;dr:
> > Is there a way to *synchronously* add / remove an object from a list
which
> > is in use by a MsgWaitForMultipleObjects call.
> >
> > I was thinking about adding a special event object just so I could get
the
> > MsgWaitForMultipleObjects call to exit, but am rather unsure if that
will
> > work and will work in a dependant way.
> >
> > Argh ...   Just thought of the problem when trying to do the adding /
> > removing from within another thread ...   In that case that "special
event
> > object" idea won't work. :-(
> >
> > Regards,
> > Rudy Wieser
>
> That's yet another internal structure thinkering.
>
> Why not simply assign the first event list slot for the
> here-is-another-event-to-wait-for event? Let the second and the remaining
> slots be available for events that got added and removed.


0
R
12/16/2016 1:01:01 AM
On Fri, 16 Dec 2016 09:13:31 +0100, R.Wieser wrote:
> 
>>> Argh ...   Just thought of the problem when trying to do the
>>> adding / removing from within another thread ...   In that case
>>> that "special event object" idea won't work. :-(
> 
> So no, I don't think that that will work in a generic way.

I think you still can. Have the other thread prepare and populate an
"instruction" structure that contains e.g. command and parameter fields;
then signal the special event.

Once the waiter thread returns from MsgWaitForMultipleObjects(), check the
structure and follow the instruction data, which can be an instruction for
putting a new object into the event list, removing an event from the list,
or do something else.
0
JJ
12/16/2016 10:54:34 AM
JJ,

> I think you still can. Have the other thread prepare and populate
> an "instruction" structure that contains e.g. command and parameter
> fields; then signal the special event.

To me that looks you're over-complicating things there.  And yes, you could
use a special event, but it would change literally nothing compared to using
a Send(Thread)Message.   The latter would actually be prefered, as it can
carry data, where the former cannot.   And where do both threads get their '
"instruction" structure ' from ?  If its global than you also need to create
some kind of synchronisation, otherwise a quick succession of an adding or
removing of an event object could trash that communication area ...

And I don't know if you are aware, but when you solve that you would have
also solved the reason why I created this thread: when can I, after removing
it from the MsgWaitForMultipleObjects array, destroy the removed event. :-)


And a heads-up:  In your previous message you mentioned that I was "internal
structure thinkering", in regard to which I asked a straight-forward
question:

> > How do *you* , for a PeekMessage loop, detect a WM_QUIT
> > being posted ? :-)

I would really like to see an answer to that.  Either explaining *how* what
I did would be "internal structure thinkering" (you might be right, but I
don't think so and have (seen) nothing to the contrary), or a kind of signal
you might have been a bit too fast with that conclusion (which can happen,
don't worry about that :-) ).

Regards,
Rudy Wieser


-- Origional message:
JJ <jj4public@vfemail.net> schreef in berichtnieuws
1qrh7r4wwcaah.f3b0586badow.dlg@40tude.net...
> On Fri, 16 Dec 2016 09:13:31 +0100, R.Wieser wrote:
> >
> >>> Argh ...   Just thought of the problem when trying to do the
> >>> adding / removing from within another thread ...   In that case
> >>> that "special event object" idea won't work. :-(
> >
> > So no, I don't think that that will work in a generic way.
>
> I think you still can. Have the other thread prepare and populate an
> "instruction" structure that contains e.g. command and parameter fields;
> then signal the special event.
>
> Once the waiter thread returns from MsgWaitForMultipleObjects(), check the
> structure and follow the instruction data, which can be an instruction for
> putting a new object into the event list, removing an event from the list,
> or do something else.


0
R
12/17/2016 1:01:01 AM
On Sat, 17 Dec 2016 08:41:55 +0100, R.Wieser wrote:
> 
> And a heads-up:  In your previous message you mentioned that I was "internal
> structure thinkering", in regard to which I asked a straight-forward
> question:
> 
>>> How do *you* , for a PeekMessage loop, detect a WM_QUIT
>>> being posted ? :-)
> 
> I would really like to see an answer to that.  Either explaining *how* what
> I did would be "internal structure thinkering" (you might be right, but I
> don't think so and have (seen) nothing to the contrary), or a kind of signal
> you might have been a bit too fast with that conclusion (which can happen,
> don't worry about that :-) ).

You can't. PeekMessage() simply doesn't peek and return a WM_QUIT message.
That's by design.

There's no other way to access the window message queue other than thikering
the internal structures which aren't documented. e.g. debug PeekMessage()
and find out how and where the actual window message queue is located, so
that you can peek it yourself.

While some internal data structures are adopted into the Win32 API
specifications, not all of them are. And they may change without notice.
0
JJ
12/19/2016 4:45:55 PM
JJ,

> You can't. PeekMessage() simply doesn't peek and return a
> WM_QUIT message.  That's by design.

I'm sorry, but you're wrong.   PeekMessage dumps the data in a structure
named MSG, and that one is described here:

https://msdn.microsoft.com/nl-nl/library/windows/desktop/ms644958(v=vs.85).a
spx

The retrieved WM_???? is, as documented, available in the 'message' field.
So, no tinkering involved.

> While some internal data structures are adopted into the Win32
> API specifications, not all of them are.

Two message back I already mentioned that that function and its arguments
(the MSG structure) are fully documented.

> And they may change without notice.

True.

And you *may* intentionally murder another person somewhere in the future.
And although I have no indication that that will ever happen, and do not see
it having a high probability of *ever* happening, should I now sever all my
ties with you (and try to have you thrown into jail as a precaution) just
because the possibility of it happening is higher than Zero ?   Really ? :-D


Bottom line: I have no idea why you think you cannot grab a WM_QUIT (or any
other message) from a PeekMessage (or a GetMessage for that matter), or why
you think that either the function or its returned data is "internal
only" -- or should be considered "subject to change" in any meaningfull way.
Sorry.

Regards,
Rudy Wieser


-- Origional message:
JJ <jj4public@vfemail.net> schreef in berichtnieuws
1v9rzpa8t2zca$.b8jlr64jcr27.dlg@40tude.net...
> On Sat, 17 Dec 2016 08:41:55 +0100, R.Wieser wrote:
> >
> > And a heads-up:  In your previous message you mentioned that I was
"internal
> > structure thinkering", in regard to which I asked a straight-forward
> > question:
> >
> >>> How do *you* , for a PeekMessage loop, detect a WM_QUIT
> >>> being posted ? :-)
> >
> > I would really like to see an answer to that.  Either explaining *how*
what
> > I did would be "internal structure thinkering" (you might be right, but
I
> > don't think so and have (seen) nothing to the contrary), or a kind of
signal
> > you might have been a bit too fast with that conclusion (which can
happen,
> > don't worry about that :-) ).
>
> You can't. PeekMessage() simply doesn't peek and return a WM_QUIT message.
> That's by design.
>
> There's no other way to access the window message queue other than
thikering
> the internal structures which aren't documented. e.g. debug PeekMessage()
> and find out how and where the actual window message queue is located, so
> that you can peek it yourself.
>
> While some internal data structures are adopted into the Win32 API
> specifications, not all of them are. And they may change without notice.



0
R
12/20/2016 5:50:58 PM
Reply: