in reply to Win32::SerialPort Error: Overlapped-I/O operation is in progress

I'm confused - you said your later changes (to allow the write to complete) solved the problem, but that doesn't explain at all why Win32::SerialPort acted differently on a restart than a non-Perl application. Where is the state informations saved, or what is Win32::SerialPort looking at that other apps don't?
  • Comment on Re: Win32::SerialPort Error: Overlapped-I/O operation is in progress

Replies are listed 'Best First'.
Re^2: Win32::SerialPort Error: Overlapped-I/O operation is in progress
by Anonymous Monk on Mar 30, 2005 at 03:08 UTC
    The Update 2 is closer to the actual issue. There is a purge_all when the port is closed (close is also called from DESTROY). When I look at the TK example I put into the CPAN distribution (eg/demo7.plx), I see a blocking write near the beginning with the comment: 
      # "write" first to init "write_done"

    [download]
    and explicit checks of write_done(0) around the Tk callbacks to prevent beginning new writes while an old one is in progress. That demo also ran with no handshaking.

    In the code given, it is not clear which internal operations are blocking/non-blocking. But he does comment on handshaking and buffer management (and uses the is_xx_limit parameters).

    I have to speculate a bit about the state information. It is not stored explicitly, although when he closes the app with characters remaining in the write buffer - but blocked by the handshaking - they are actually in the serial driver's buffer (during an "overlapped", i.e. non-blocking TO PERL background write). It is not clear if both Perl and Tk are closed before restarting. He may be holding an OS handle open. But I don't know for sure.

    I do think flushing the buffer on close (e.g. by setting handshake to 'none' or doing a blocking write) will fix the problem.

    -bill

    Edit by tye: Preserve formatting

[reply]
[d/l]
      Hi Bill,

      Thanks for taking the time to comment. Sorry about the confusion surrounding my post. Both Perl and Tk were closed before restarting.

      There are actually two issues here. One regards closing the port with characters remaining. The sensible approach, I think, would be for the system just to empty the buffer on a close, rather to wait for any handshaking to unblock (which may never happen) or to leave the port in a closed-but-nonempty state. If the programmer is concerned about those last characters getting to the connected device (I'm not), he can check the transmit buffer and wait for it to empty before issuing the close command. But when a close is issued, it should mean just that -- graceless though it might be -- regardless of state. And the system should be relied upon to mop up any messes left behind.

      The second issue regards opening a port that's in this weird state of limbo. Non-Perl apps don't seem to have a problem recognizing that the port can be forced back open and proceed accordingly without complaint. It would be nice if Perl apps could do the same.

[reply]

In Section Seekers of Perl Wisdom