Return to readme CVS log

Up to [WindowsNT SDKs] / q_a / samples / event

Annotation of q_a/samples/event/readme, revision 1.1.1.1

1.1       root        1:  Sample: Asynchronous I/O Demonstration
                      2: 
                      3: Summary:
                      4: 
                      5: The EVENT sample demonstrates perfoming asynchronous I/O in
                      6: Win32.  In Win32 you are able to do this in two ways.  One
                      7: is similar to OS/2 where a thread was spawned which did the
                      8: IO and returned. With Win32, when you create a file it is
                      9: able to signal to the system that you wish to perform I/O
                     10: asynchronously.  Then when, say, ReadFile is going to take a
                     11: significant amount of time to complete it will generate
                     12: ERROR_IO_PENDING. This signals to you to go about doing
                     13: other tasks till you NEED the data.  At which time you will
                     14: use the function GetOverlappedResults which will finish the
                     15: I/O.
                     16: 
                     17: More Information:
                     18: 
                     19: Note this has all been done without the need of an
                     20: additional thread to perform the work. This sample only
                     21: touches on the capabilities of what one can do with the new
                     22: overlapped I/O functions. For example an application that
                     23: uses pipes to communicate over the network to other clients
                     24: can create these file handles with the overlapped flag.
                     25: Then instead of blocking and waiting for a connection the
                     26: server app can go about doing useful tasks waiting for the
                     27: pipe to enter the "signaled" state. Another even more exotic
                     28: feature of files created this way is you are able to perform
                     29: more than one operation on this handle at one time such as
                     30: reading and writing to the same file.
                     31: 
                     32: All this power does not come with out some responsibilities
                     33: on the programmer's side. First the system does not keep
                     34: track of the system file pointers as you are no doubt used
                     35: to. And naturally just because the call returns imediately
                     36: you are NOT able to use the data until the system responds
                     37: by setting an event to a signaled state.
                     38: 
                     39: In the first case this simply means you need to keep track
                     40: of the value "lpNumberOfBytesTransfered" returned by
                     41: GetOverlappedResult and update the OVERLAPPED structure with
                     42: this information. This structure OVERLAPPED will then be
                     43: passed into the Read/Writefile function which will use this
                     44: as the offset to starting point for the I/O operation. The
                     45: first call to Read/Writefile will normally then have the
                     46: offset fields in the OVERLAPPED structure set to zero. The
                     47: second case should be used as a criteria of whether to use
                     48: this type of I/O obviously if you need the data before you
                     49: can do anything else you may as well use normal sychronous
                     50: I/O and let the system handle the details for you. This also
                     51: demonstrates an important reason for using an EVENT to wait
                     52: on rather than the file handle. While both are allowed in a
                     53: multithread application one could not gaurantee that the
                     54: thread which set the handle to the signalled state would be
                     55: the one returning from the GetOverlappedResult since each
                     56: thread was using the same handle to wait on.
                     57: 
                     58: Inorder to keep this sample focused, the user interface is
                     59: simple.  To run this sample at the command prompt type:
                     60: 
                     61:      ASYNC_IO <In_file> <Out_file>
                     62: 
                     63: where In_file and Out_file are place holders. As this is
                     64: implemented you are not able to write over an existing file.
                     65: While this app is running you will see the vital statistics
                     66: such as:
                     67: 
                     68:   When IO is pending
                     69:   How many bytes are transfered
                     70:   End of file
                     71: 
                     72: 
                     73: 

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.