I found the article where it is mentionned that read and write operations on a message-type named pipes are treated as if WRITE_THROUGH mode was enabled.
The description of the FILE_FLAG_WRITE_THROUGH option goes like this:
Write-through mode is enabled. This mode affects only write operations on byte-type pipes and, then, only when the client and server processes are on different computers.
No matter what the answer is, is it possible to achieve asynchronous I/O with message-type named pipes?
Yes for read operations. For write operations I don't know if will block or not. However what seems more significant is that the efficiency will not occur:
If this mode is not enabled, the system enhances the efficiency of network operations by buffering data until a minimum number of bytes accumulate or until a maximum time elapses.
That information also speaks to the different ways data transmission libraries use buffering that may or may not effect user code that is reading/writing using the libraries which is what you have been seeing.
Now in your early posts you indicated that your team decided to use named pipes for efficiency reasons. Following that decision I would not think the write through option is appropriate for your solution so your concern over overlapped operations in that mode seems inappropriate.
Same principles apply to pipes (which very well may be using sockets underneath).
Like I stated in my other reply to you here, you need to check if all the bytes you request to send and receive
actually get sent and received. If not, then you need to continue sending and receiving until you do.
You are correct of course but Benjamin has some "fundamentals" problems that he needs to get straight before any of that matters. See my last post, it's a common theme (struggling to grasp the concepts) that occurs with an introduction into both subjects, threading and asynchronous operations. Actually for me, anytime I have a gap in time of doing either, I go through the struggle each time I have to do it again.
it's a common theme (struggling to grasp the concepts) that occurs with an introduction into both subjects, threading and asynchronous operations.
Indeed
led mike wrote:
Actually for me, anytime I have a gap in time of doing either, I go through the struggle each time I have to do it again.
Heh it's like that for me with anything. That's probably the biggest reason I respond to questions here - so I can keep
a little sharp on stuff I don't use often. Graphics, asynchronous I/O, and threading, however, I do every day, all day.
I tried something like that but it would not work. I put the ReadFile in a while loop and I changed the offset of the buffer and the number of bytes to read by an amount I got from a call to GetOverlappedResult but it gave me weird results.
I guess led mike is right when he says that there is fundamental things I need to understand before getting things right.
Thanks for your comment and suggestion.
Benjamin Racette
CAE software developer
racette@cae.com
Does a call to GetOverlappedResult() keeps on reading or writing or should I call WriteFile or ReadFile again and again until its done?
You are responsible for checking the overlapped result and sending/receiving any remaining bytes.
FWIW, if you are calling GetOverlappedResult() right after a function call fails with ERROR_IO_PENDING,
then you're essentially doing synchronous I/O, and all you've done is added complexity to the code.
hey, that's nice to answer, but you know, we have dedicated forums, so if a question is asked at the wrong place, we shouldn't answer, because it will encourage others to ask anywhere.
I see you also answered the "Time" Question. Same remark applies there too.
actually, he was too much asking for somthing that looks like "please do my homework for me 'cause i didn't listen to the professor and now I don't know how to do that simple code"...
that's why, before giving him some working code, i prefered ask him first what he had already tried & written...
Have you extracted the date/time from the control using the DTM_GETSYSTEMTIME message or GetTime() method?
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
Hi,
I have created a 'please wait' dialog which is loaded when a user clicks on a button. A new thread is launched to load the button so the main thread can continue what it is doing.
The button code;
CPleaseWait *dlgWait = new CPleaseWait(this);<br />
AfxBeginThread(PleaseWaitThread, dlgWait);
It is very simple code, which I have had working before.
The problem is that when called, DoModal never returns, so the dialog doesnt get displayed (it doesnt get as far as InitDialog). The main thread continues running however.
If I place a 'return;' directly after the AfxBeginThread() then the dialog DOES display. If I place 'while(1) Sleep(100);' (or any other code) after the AfxBeginThread() then it does not return.
I have narrowed the problem down to a particular line (510) within 'dlgcore.cpp'
You're using a worker thread to create a user interface object?
Personally I dont see the need for a thread at all.
On Button Click:
Disable the main window.
Create and show a modeless please wait dialog.
Do work.
Destroy the modeless please wait dialog.
Enable the main window.
I think you are mixing the parent between threads, what about having the new CPleaseWait with (NULL) ??
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
Your Thread Dialog wants to disable the main dialog.
There can be only one modal dialog per Thread. -> Parent = NULL or modeless Dialog (tip: with new and self destruction)
Greetings from Germany
Last Visit: 31-Dec-99 18:00 Last Update: 11-Oct-24 4:18
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
