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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest