Bug in Win32file WaitCommEvent ???

[Mark Hammond]

Grant Edwards wrote:
> In article <3dde5012$0$4491$a1866201 at newsreader.visi.com>, Grant Edwards wrote:
> 
>>>I don't have win32all, but don't you need to have the
>>>OVERLAPPED struct persist as well? Isn't the event slot there
>>>also used asynchronously?
>>
>>Yes, the OVERLAPPED struct has to be persistent.  I've thought
>>about using that as storage for the comm event mask value, but
>>then we've got to add some sort of accessor function to
>>retreive it later.  The advantantage of using a 4-byte buffer
>>is that the semantics stay more similar to both the Win32
>>usage, and the way that data buffers work for overlapped
>>read/write operations:
>>
>>
>>   rc,mask = WaitCommEvent(handle,overlapped)
>>   rc = WaitForSingleObject(overlapped.hevent)
>>   whatHappened = int(mask)
> 
> 
> I should have mentioned that in the non-overlapped case, the
> returned mask value would be an integer (same as it is now).
> That way the only change is to the overlapped usage.

Actually, I don't mind the idea of attaching it to the overlapped 
object.  We already have the concept of attaching an object to an 
overlapped structure, so adding support for a generic "flags" 32 bit 
value wouldn't hurt, and 2 bytes per Python-allocated overlapped 
structure wont kill anyone.

Might be overkill if this is the only case we come across, but it 
doesn't change any semantics.  ie, the code would look like:

    rc,mask = WaitCommEvent(handle,overlapped)
    rc = WaitForSingleObject(overlapped.hevent)
    whatHappened = overlapped.flags


Also much easier for me to code ;)  Would only work for overlapped 
objects created via Python, but I think that is reasonable.  If a non 
Python overlapped structure is used, we pass the address of a static 
variable to ensure no one ever crashes.

Sound reasonable?

Mark.