Hello all,

I'm trying to build a small app that should respond on an incoming
mailslot-message, and have a question about that : all I can find is the
GetMailslotInfo and examples that use it in a polling-loop

My question : is there any way to let an incoming message somehow generate
an event or post a message into the queue ?

Regards,
Rudy Wieser

R.Wieser wrote:
bothering with GetMailslotInfo()?

--
J.
http://symbolsprose.blogspot.com

Hello Jeroen,

Nope. I must say I have never tried to use such a structure, as its not
quite clear to me what it does (and I'm not tutored, so I have to find it
out for myself. With help of the 'Net ofcourse :-) )

But how would that help me in *not* having to use a polling-loop ?

Regards,
Rudy Wieser


Jeroen Mostert <jmostert@xs4all.nl> schreef in berichtnieuws
4839cc2c$0$14345$e4fe514c@news.xs4all.nl...

R.Wieser wrote:
"overlapped I/O" in the docs), which eliminates the need for polling
altogether. I could explain it, but I see little point in duplicating
Microsoft's own documentation: http://msdn.microsoft.com/library/ms686358.aspx

Mailslots support asynchronous I/O, though I've never used them and
therefore cannot tell you if there are specific issues to look out for.

--
J.
http://symbolsprose.blogspot.com

In article <4839bb4b$0$3274$e4fe514c@dreader32.news.xs4all.nl >,
address@not.available says...
When you read from the mailslot, you can specify an OVERLAPPED
structure, including the handle to an event that will be triggered when
the read succeeds. Here's a mailslot server that creates a mailslot,
then does overlapped read, waits on the associated event, and processes
each message (in this case, just prints it out as text to show what was
received):

#include <windows.h>
#include <stdio.h>

void process_message(char *buffer) {
printf("%s\n", buffer);
}

int main() {

HANDLE mailslot = CreateMailslot("\\\\.\\mailslot\\myslot",
0,
MAILSLOT_WAIT_FOREVER,
NULL);
if (mailslot == INVALID_HANDLE_VALUE) {
fprintf(stderr, "Unable to create mailslot.");
return 1;
}

char buffer[100];
OVERLAPPED ovlp = {0};

ovlp.hEvent = CreateEvent(NULL, false, false, NULL);

if (ovlp.hEvent == NULL) {
fprintf(stderr, "Unable to create Event.");
return 2;
}

DWORD read;

do {
ReadFile(mailslot, buffer, sizeof(buffer), &read, &ovlp);
buffer[read] = 0;
WaitForSingleObject(ovlp.hEvent, INFINITE);
process_message(buffer);
} while (strcmp(buffer, "exit"));

return 0;
}

Here's a matching client that will talk to the server above:

#include <windows.h>
#include <stdio.h>

int main() {

HANDLE mailslot = CreateFile("\\\\.\\mailslot\\myslot",
GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL,
OPEN_ALWAYS,
0,
NULL);

if (INVALID_HANDLE_VALUE == mailslot) {
fprintf(stderr, "Unable to open mailslot.\n");
return 1;
}
char buffer[100];
DWORD written;

while (fgets(buffer, sizeof(buffer), stdin)) {
strtok(buffer, "\n");
size_t len = strlen(buffer)+1;
WriteFile(mailslot, buffer, len, &written, NULL);
if (len!=written) {
fprintf(stderr, "Write to mail slot failed.\n");
return 1;
}
}

fprintf(stderr, "Writing exit message to mailslot.");
WriteFile(mailslot, "exit", 4, &written, NULL);
if (written != 4) {
fprintf(stderr, "Write to mailslot failed.\n");
return 1;
}
return 0;
}

To play with these, you must start the server first (it creates the mail
slot) then the client (which opens the mailslot, and will fail if the
server hasn't already created it).

For the moment, the overlapped read in the server doesn't really
accomplish much -- it shows how to wait on the event, but when the wait
immediately follows the ReadFile (and only waits on that one event) it's
basically equivalent to synchronous read.

Of course, with a UI you'd typically use MsgWaitForMultipleObjects so
you could process triggered events and/or incoming messages.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Hello Jeroen,

Thanks for the link, I'll be sure to look into it.

Regards,
Rudy Wieser


Jeroen Mostert <jmostert@xs4all.nl> schreef in berichtnieuws
4839eac5$0$14342$e4fe514c@news.xs4all.nl...

Hello Jerry,

Thanks for your reply, but the code you posted looks to be, in effect, the
same as using the GetMailslotInfo with an infinite time-out and than read
the returned data. In other words : I do not see any advantages to your
posted method.

Allso, the code you posted allso pretty-much freezes the program (thread)
its in, which would mean I would need to put it into its own thread (so the
normal windows-messages can get handled).

Is there any possibility that I let the event generate a windows-message
(SendMessage / PostMessage), so I can go on do my normal buisiness and only
look at the mailslot when I see such a message come by ?

Regards,
Rudy Wieser


Jerry Coffin <jcoffin@taeus.com> schreef in berichtnieuws
MPG.22a3ebec37ff42a989ce3@news.sunsite.dk...

In article <483a73e1$1$3296$e4fe514c@dreader30.news.xs4all.nl >,
address@not.available says...
Here's what that post said about this:

IOW, yes, at the moment, what it contains is essentially equivalent to a
synchronous read that freezes the thread -- but, that's only the
WaitForSingleObject, _not_ the ReadFile. Generally you don't call
WaitForSingleObject until/unless your thread has nothing to do until a
message arrives.

Here's what my post said about that:

MWFMO allows you to specify a set of handles (e.g. the handle to the
event). It returns under either of two conditions: 1) one of the handles
is signaled, or 2) there's a message to process.

This allows you to process messages so your UI remains responsive, AND
process messages from the mailslot when they arrive -- withOUT polling
for either one, so your process consumes no CPU time except when
processing is needed.

If you _really_ want to, you could create a separate thread, and execute
the WaitForSingleObject in that thread, then when the handle is
signaled, post a message back to the main thread telling it there's a
message to process.

This might even be a decent design under some circumstances. It wouldn't
be my first (or even second) choice though. My first choice would be to
use MsgWaitForMultipleObjects and do all the processing in one thread.

If I was going to create a thread to deal with the mailslot, I'd
delegate as much of the responsibility for the mailslot to that thread
as possible. The UI thread would then deal exclusively with the UI, and
the mailslot thread with the mailslot. The mailslot thread could then
post messages to the UI thread when/if there was something relevant to
the UI, but NOT leave the mailslot processing to the UI thread.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Hello Jerry,

<snip>

My apologies. I looked at the code and forgot to (carefully) read the text
accompanying it.

I do remember having seem the MsgWaitForMultipleObjects command (even before
posting my message in this newsgroup), but did not quite see how it could
help me (I thought it would do something else altogether). So thanks for
your explanation of it and I'll look if I can implement it.

Regards,
Rudy Wieser


Jerry Coffin <jcoffin@taeus.com> schreef in berichtnieuws
MPG.22a485f8aec4c3e2989ce7@news.sunsite.dk...

In article <483aeb13$0$3526$e4fe514c@dreader26.news.xs4all.nl >,
address@not.available says...

[ ... ]

An easy and understandable accident.

I think it should be useful for your purposes. One caveat: its
documentation has a warning that you really need to read and follow
carefully: more than one thing can trigger it, and if so you need to
process all of them before you call it again. For example, a message
might arrive essentially concurrently with one of the handles being
signaled. If so, you need to process the message AND the signaled handle
THEN call MsgWaitForMultipleObjects again -- if you just handle the
message, the signaled handle will (assume it's auto-reset) be reset as
soon as your thread is activated, whether you process the associated
data or not.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Hello Jerry,

Thanks for the waring and I'll do.

Regards,
Rudy Wieser


Jerry Coffin <jcoffin@taeus.com> schreef in berichtnieuws
MPG.22a4a58ed9845cb0989ceb@news.sunsite.dk...