Bug in Win32file WaitCommEvent ???

Bengt Richter bokr at oz.net
Wed Nov 20 09:35:55 EST 2002


On 20 Nov 2002 01:07:57 GMT, Grant Edwards <grante at visi.com> wrote:

>In article <areli6$ris$0 at 216.39.172.122>, Bengt Richter wrote:
>
>>==== from an old win32 help file that may have come with an old version of Delphi ?? ======
>> 
>>   If the overlapped operation cannot be completed immediately, the function returns FALSE and
>>   the GetLastError function returns ERROR_IO_PENDING, indicating that the operation is executing
>>   in the background. When this happens, the system sets the hEvent member of the OVERLAPPED
>>   structure to the not-signaled state before WaitCommEvent returns, and then it sets it to the
>>   signaled state when one of the specified events or an error occurs. The calling process can
>>                                                                         ^^^^^^^^^^^^^^^^^^^^^^^ 
>>   use a wait function to determine the event object's state and then use the GetOverlappedResult
>>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>   function to determine the results of the WaitCommEvent operation. GetOverlappedResult reports
>>                                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>   the success or failure of the operation, and the variable pointed to by the lpfdwEvtMask
>>                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>   parameter is set to indicate the event that occurred. 
>>   ^^^^^^^^^^^^^^^^
>> 
>>   If a process attempts to change the device handle's event mask by using the SetCommMask
>>   function while an overlapped WaitCommEvent operation is in progress, WaitCommEvent returns
>>   immediately. The variable pointed to by the lpfdwEvtMask parameter is set to zero. 
>> 
>>==========================================
>> 
>> Sounds like the mask location is safe if you don't call
>> GetOverlappedResult??
>
>I sure don't know.  I've found examples that don't call GetOverlappedResult
>and they expect a "delayed" write to *lpfdwEvtMask happen.
>
"""
  If the lpo parameter is NULL or the hCommDev handle was opened without specifying
    the FILE_FLAG_OVERLAPPED flag, WaitCommEvent does not return until one of the specified
    events or an error occurs. 
"""

Did the examples use the FILE_FLAG_OVERLAPPED flag and provide the lpo parameter for sure?
Otherwise there is apparently an implicit wait.

>And I thought it impossible for me to grow to hate Windows even more...
>
Well, try to make your solutions portable ;-)

Regards,
Bengt Richter



More information about the Python-list mailing list