From Newsgroup: alt.windows7.general

Hello all,

I would like to write some single-threaded code to work with a single non-blocking, non-overlapped (incoming) named pipe, in combination with MsgWaitForSingleObject - the latter as part of the message-loop.

The problem is that although it looks like I can wait /something/ to happen with the pipe, I do not see how I can get *what* is happening : A new connection (ConnectNamedPipe), or data coming in (ReadFile).

Does anyone have an idea ? Some example code perhaps ?

Regards,
Rudy Wieser

p.s.
I was thinking of using a flag indicating the current mode, but that would
not work well if I ever decide to accept more than a single connection. :-|


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Richard,

I would like to write some single-threaded code to work with a
single non-blocking, non-overlapped (incoming) named pipe, in
combination with MsgWaitForSingleObject - the latter as part of
the message-loop.

Well, if you want to do non-blocking I/O on Win32, that is done
using FILE_FLAG_OVERLAPPED when you create the pipe.

You mean that the PIPE_NOWAIT flag is just thrown in there for shits-and-giggles, but doesn't actually /do/ anything ? :-)

"Overlapped I/O" on Win32 just means asynchronous non-blocking I/O.

And that, it being asynchronous, is exactly what I'm trying to evade.

The problem is that MsgWaitForSingleObject can't wait on a pipe,
it can only wait on kernel synchronization objects: events,
mutexes, processes.

That would throw quite a wrench into my idea. :-|

FYI, I got this answer by literally copy/pasting your question
into google's AI (gemini), but I reviewed the Win32 API
documentation to verify that the suggested approach makes sense.

:-) You can ask an AI for information, but to be able determine if what it says makes sense smeans you till need to know your stuff (or you stand the chance to repeat its "hallucinations" as facts).

[snip code]

Thanks for that.

Regards,
Rudy Wieser


--- Synchronet 3.21e-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Richard, (others),

HANDLE hConnectEvent = CreateEvent(NULL, TRUE, TRUE, NULL); // Manual
reset
HANDLE hReadEvent = CreateEvent(NULL, TRUE, FALSE, NULL);

Any idea why one is created set, and the other not ? As far as I can see
both should be created reset.

Also, any idea why they are (must be?) created as manually-reset events ?

The MSDN docs says that the WaitFor functions change (reset) the event that causes it to return. Any idea to whats the reason for wanting to do it manually ?

Regards,
Rudy Wieser


--- Synchronet 3.21e-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

R.Wieser wrote:
Hello all,

I would like to write some single-threaded code to work with a single non-blocking, non-overlapped (incoming) named pipe, in combination with MsgWaitForSingleObject - the latter as part of the message-loop.

The problem is that although it looks like I can wait /something/ to happen with the pipe, I do not see how I can get *what* is happening : A new connection (ConnectNamedPipe), or data coming in (ReadFile).

Does anyone have an idea ? Some example code perhaps ?

Regards,
Rudy Wieser

p.s.
I was thinking of using a flag indicating the current mode, but that would not work well if I ever decide to accept more than a single connection. :-|

You cannot really do this cleanly with a non overlapped named pipe.

If you wait on the pipe handle in a message loop, Windows can tell you that something happened, but not in a way that neatly identifies whether that means a pending connection completed or data is ready to read. With non blocking, non overlapped pipes, you usually end up having to call ConnectNamedPipe or ReadFile and then inspect the result yourself as part of a manual state machine.

So the practical answer is that this design is the wrong fit for what you want. If you need to integrate a named pipe into a message loop and know what operation completed, the normal Windows solution is overlapped I O with event objects. Then you can wait for the message queue and for specific pipe events in the same loop.

For a single connection you could keep a state flag such as "waiting for connect" versus "connected, waiting for read" and then try the appropriate call when the handle wakes up, but that gets awkward quickly and does not scale well once you want more than one client.

So the real answer is that if you want this to work properly, especially in a single threaded message loop, use overlapped named pipes.


This is a response to the post seen at: http://www.jlaforums.com/viewtopic.php?p=702617176#702617176
--
[via JLA Forums] alt.windows7.general on the web: http://www.jlaforums.com/viewforum.php?f=422
--- Synchronet 3.21e-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

In comp.os.ms-windows.programmer.win32 R.Wieser <address@is.invalid> wrote:

"Overlapped I/O" on Win32 just means asynchronous non-blocking I/O.

And that, it being asynchronous, is exactly what I'm trying to evade.

Why?

It seems to me that you want async semantics in the sense that the
program should process UI messages, and process pipe input, and not
block on either. Using a nonblocking pipe without async support
would mean an attempt to call ReadFile would fail when no data exists.

Is the advantage of avoiding async that it avoids allocating a buffer
and providing it to the named pipe driver to populate whenever it wants?
But calling it in a polling way still requires allocating that
buffer...?
--- Synchronet 3.21e-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

malxau,

And that, it being asynchronous, is exactly what I'm trying
to evade.

Why?

It seems to me that you want async semantics in the sense that
the program should process UI messages, and process pipe input,
and not block on either.

Putting stuff thru a message-pump synchronises them.

Regards,
Rudy Wieser


--- Synchronet 3.21e-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Putting stuff thru a message-pump synchronises them.

Perhaps better said : serializes them.

Regards,
Rudy Wieser


--- Synchronet 3.21e-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

HANDLE hConnectEvent = CreateEvent(NULL, TRUE, TRUE, NULL); // Manual
reset
HANDLE hReadEvent = CreateEvent(NULL, TRUE, FALSE, NULL);

Any idea why one is created set, and the other not ? As far as I can see both should be created reset.

Also, any idea why they are (must be?) created as manually-reset events ?

I came across this one today :

https://www.globalnerdy.com/wp-content/uploads/2026/03/652575612_1355710716577270_799259824397935466_n.jpg

I find it rather apropriate.

By the way : My test code using non-manual resetting events, both created as not-set seems to work alright.

Regards,
Rudy Wieser


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

"R.Wieser" <address@is.invalid> spake the secret code <10pf318$629m$1@dont-email.me> thusly:

:-) You can ask an AI for information, but to be able determine if what it >says makes sense smeans you till need to know your stuff (or you stand the >chance to repeat its "hallucinations" as facts).

It's been decades since I studied the low-level objects in Win32, but
a book I can recommend is "Advanced Windows" by Jeffrey Richter. I'm
sure you can find a used copy for cheap.

<https://amzn.to/4rSTGKK> has paperback copies listed for ~$7.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Richard,

It's been decades since I studied the low-level objects in Win32,
but a book I can recommend is "Advanced Windows" by Jeffrey Richter.
I'm sure you can find a used copy for cheap.

A quick web-search shows there are PDF versions galore, with "last version" dates upto 2024 (none of them actually download though).

But in my case its not a question of finding *a* method, but a *specific* method.

In my case I assumed that I could catch events using the pipes "file"
handle. I was wrong. Perhaps that was why my web-searches did not turn up anything about it. :-)

Thanks for the book suggestion though.

Regards,
Rudy Wieser


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

"R.Wieser" <address@is.invalid> spake the secret code <10ps8n2$fsu7$1@dont-email.me> thusly:

Thanks for the book suggestion though.

I like a good programming book that gives me the big picture and
guides me on the details. The reference documentation for Win32 is
great for describing the details of every API function, but somewhere
along the way MSDN lost the "user guide" type of documentation that
orients you on the big picture.

It seems good programming books are going out of style now that
stackoverflow and AI assistants are answering people's questions
immediately, but these core synchronization/system objects in Win32
haven't changed much over the decades so the old books still have
useful content.

I use the web and chatbots for lots of things but there's still a role
for books IMO.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
--- Synchronet 3.21f-Linux NewsLink 1.2