Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #109 > unrolled thread

Re: detecting if space is available in a named pipe

Back to article view | Back to comp.programming.threads

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: detecting if space is available in a named pipe Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-02 01:18 +0100
    Re: detecting if space is available in a named pipe torri <vincent.torri@gmail.com> - 2011-05-02 05:39 +0000
      Re: detecting if space is available in a named pipe David Schwartz <davids@webmaster.com> - 2011-05-02 03:55 -0700
        Re: detecting if space is available in a named pipe torri <vincent.torri@gmail.com> - 2011-05-02 17:02 +0000

#109 — Re: detecting if space is available in a named pipe

> Is there some equivalent for writing (that is, a function that checks 
> if named pipe is not full). I would like to not use WriteFile for that.
>
WriteFile(), or even WriteFileEx(), is exactly what you should be using 
for that.  I can almost hear David Schwartz now: Think about what you 
are doing and why you want to know what you say you want to know.  The 
only real use for knowing whether there is "more room in the pipe" is to 
determine whether the next call to WriteFile() will block or not.  
That's the only thing that such information really tells you (and, 
depending from client-end application design, may not even tell you that 
fact).  Thus what you are really doing is trying to ensure that calls to 
WriteFile() never block, and that when they would your thread can do 
something else until the pipe drains, or at least wait for things other 
than just the completion of the write I/O request.  The proper design 
for this, which the MSDN Library documentation actually tells you to use 
pretty much explicitly, is to use overlapped I/O.  Use an overlapped I/O 
capable pipe handle, and WriteFile() with an OVERLAPPED structure to 
perform overlapped I/O.  You can continue doing things, or 
WaitForMultipleObjects() on both the overlapped I/O event and other 
things, and pump a new write request down the pipe whenever the 
preceding asynchronous one completes.

Or, in other words: Don't design as if you can poll the pipe status and 
busy wait.  Design so that completion of a write request on the pipe is 
an event that you can block waiting for in amongst all of the other 
events that you might be waiting for.  Stick with the event-driven paradigm.

[toc] | [next] | [standalone]

#110

On Mon, 02 May 2011 01:18:07 +0100, Jonathan de Boyne Pollard wrote:

>> Is there some equivalent for writing (that is, a function that checks
>> if named pipe is not full). I would like to not use WriteFile for that.
>>
> WriteFile(), or even WriteFileEx(), is exactly what you should be using
> for that.  I can almost hear David Schwartz now: Think about what you
> are doing and why you want to know what you say you want to know.  The
> only real use for knowing whether there is "more room in the pipe" is to
> determine whether the next call to WriteFile() will block or not. That's
> the only thing that such information really tells you (and, depending
> from client-end application design, may not even tell you that fact). 

Ok. To be a bit more precise, I want to port a framework application from 
unix to windows (AF_UNIX connections). I try to mimic the code, but i'm 
realizing that I should use another design. It's not easy for me, as I'm 
not a Windows coder.

> Thus what you are really doing is trying to ensure that calls to
> WriteFile() never block, and that when they would your thread can do
> something else until the pipe drains, or at least wait for things other
> than just the completion of the write I/O request.  The proper design
> for this, which the MSDN Library documentation actually tells you to use
> pretty much explicitly, is to use overlapped I/O.  Use an overlapped I/O
> capable pipe handle, and WriteFile() with an OVERLAPPED structure to
> perform overlapped I/O.  You can continue doing things, or
> WaitForMultipleObjects() on both the overlapped I/O event and other
> things, and pump a new write request down the pipe whenever the
> preceding asynchronous one completes.

I won't touch overlapped I/O. It's an horror to correctly use. I've tried 
to use it, but documentation is very very very poor. I've lost 2 months 
trying to make it working correctly (in a specific case), i won't loose 
more time.

> Or, in other words: Don't design as if you can poll the pipe status and
> busy wait.  Design so that completion of a write request on the pipe is
> an event that you can block waiting for in amongst all of the other
> events that you might be waiting for.  Stick with the event-driven
> paradigm.

yes, that is what i'll do, i think.

thank you

[toc] | [prev] | [next] | [standalone]

#111

On May 1, 10:39 pm, torri <vincent.to...@gmail.com> wrote:

> I won't touch overlapped I/O. It's an horror to correctly use. I've tried
> to use it, but documentation is very very very poor. I've lost 2 months
> trying to make it working correctly (in a specific case), i won't loose
> more time.

I'm sympathetic, but this is precisely the mindset that creates a lot
of very low quality Windows code. People are familiar with UNIX
programming and they come to Windows and they try to make Windows work
like the UNIXes they're familiar with. But Windows is not UNIX. There
is a Windows way, and your programs will work a lot better if you take
the time to learn the Windows way.

I'm not sure how you wound up with two months of pain trying to get
overlapped I/O to work. It's an incredibly elegant mechanism and I've
wished many times that UNIXes had a similar mechanism. I/O completion
ports are especially convenient, combining descriptor discovery with
thread dispatch.

DS

[toc] | [prev] | [next] | [standalone]

#113

On Mon, 02 May 2011 03:55:28 -0700, David Schwartz wrote:

> On May 1, 10:39 pm, torri <vincent.to...@gmail.com> wrote:
> 
>> I won't touch overlapped I/O. It's an horror to correctly use. I've
>> tried to use it, but documentation is very very very poor. I've lost 2
>> months trying to make it working correctly (in a specific case), i
>> won't loose more time.
> 
> I'm sympathetic, but this is precisely the mindset that creates a lot of
> very low quality Windows code. People are familiar with UNIX programming
> and they come to Windows and they try to make Windows work like the
> UNIXes they're familiar with. But Windows is not UNIX. There is a
> Windows way, and your programs will work a lot better if you take the
> time to learn the Windows way.

When I read in eggheadcafe forum that the equivalent way of AF_UNIX 
connections is named pipe on Windows and they have the same semantic, 
then, I am confident and I think that it's the same design. But actually, 
it's not at all the same design. 

I don't mention all the other comments in newsgroups and forums saying 
that overlapped I/O is better / worse than completion routines, which are 
also better / worse than I/O completion port.

> I'm not sure how you wound up with two months of pain trying to get
> overlapped I/O to work. It's an incredibly elegant mechanism and I've
> wished many times that UNIXes had a similar mechanism. I/O completion
> ports are especially convenient, combining descriptor discovery with
> thread dispatch.

there is no link between an elegant mechanism and the fact that it's 
difficult to use a technic :

1) the doc in MSDN about overlapped I/O and named pipe is just a joke. I 
read every functions and examples.

2) there is NO example or precise document about overlapped I/O with 
named pipe and the case when the data send to a pipe is longer than the 
buffer of ReadFile. The number of times that i read : "for sake of 
simplicity, we do ***" is countless. And the problem is that they do not 
describe my specific case because of the simplification of the corner 
cases...

With all that stuff, how can you imagine that someone who try to learn 
how to use named pipe in a specific case, without help except the web, 
can know everything in 2 months ?

You are certainly a great Windows programmer, you maybe have been taught 
Windows programming, you maybe have years of Windows programming, you 
maybe have several books about Windows programming.

I have none of that and I do what I can.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web