[PD] preventing comport freezes

[martin.peach at sympatico.ca]

Roman wrote:
> On Fri, 2009-05-08 at 08:14 -0400, Martin Peach wrote:
> > Hans-Christoph Steiner wrote:
> > > 
> > > So right now, when [comport] is open and that device gets disconnected, 
> > > comport freezes and Pd crashes.  My guess is that comport is waiting and 
> > > therefore blocking.  It seems like the select() call should prevent 
> > > that, any other guesses on how to prevent comport from locking like 
> > > this?  Many arduino users would be very happy.
> > > 
> > 
> > Is this on linux? It should be non-blocking on Windows.
> > I suppose it crashes only when you try to send something, not if you 
> > just pull the cable out. I would have thought that if hardware 
> > handshaking was off, the port will send anyway. I seem to remember 
> > sending into an oscilloscope probe with no cable present.
> 
> > Select is problematic, as we have seen with recent [tcpserver], checking 
> > if each byte can be sent before it goes out slows the whole thing down a 
> > lot.
> > 
> 
> i am still in the process of understanding things, that you have to deal
> with, so forgive any obvious question from my side, but why is it
> necessary to call select() for each single byte? wouldn't it be
> sufficient to call it 'from time to time' (whatever that means)?
> 

I guess if you pull the cable out at the exact moment that [tcpserver] is sending a message, every once in a while it might hang because select said it was clear to send, but right after that the connection broke...

> just out of curiosity: if there is a solution, that works well for
> [tcpserver], couldn't it be applied also to [comport]?
> 


Maybe. But I think you should be able to use [comport] with no hardware handshaking enabled and send data even if no cable is attached. Sometimes the absence of one of the two input handshake signals prevents the serial hardware from sending. Also if an error occurred in the reception of serial data it may not be handled properly in [comport]. So I'm not sure what is causing this particular crash, since HC said that it happened when the remote device was disconnected but gave no further detail.

Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090508/66d1f3b1/attachment.htm>