[Interest] Crash in QSerialPort when closing?

[Tony Rietwyk]

Seam wrote:

> Sent: Friday, 31 October 2014 12:43 AM
> 
> > Closing a device within a read slot sounds dodgy anyway.  In these
> > cases, I usually do QTimer::singleShot(0, ...) and do the close in that
slot.
> 
> I thought about doing the single shot as well.
> 
> Is there a more concrete reason (other than it sounding "dodgy") that you
> feel like the way I'm currently doing it is not a good idea?
> 
> In my use case, I've already sent the "I would like to disconnect" command
to
> the external device, and I'm waiting for a short acknowledge response.  In
> my readyRead() slot, I validate that response, which means that the
external
> device is in an idle state, listening, so I'm not expecting to receive any
more
> bytes.  So at this point, I'm ready to close the connection.
> 
> Sean

I don't have anything more concrete than the example you've already pointed
out!  Qt coders have to do special things to handle these cases around the
emit call - which was presumably not done correctly in the original version
of serial port.  A device often has associated buffers, state flags and
other resources that are released or modified when you close the device.
Doing that in the middle of a read event assumes that the event has
completely finished with the resources and state flags.  

I suppose a different way of thinking about it is to look at the code in a
procedural context:  You would normally open the device, loop reading until
an end condition, then close the device.  It would be weird for the read or
set-end-condition routines to close the device as well - since you may want
to reset the device and read again in a separate loop, without having to
reopening it.  

Regards, 

Tony