[PD] preventing comport freezes

[Roman Haefeli]

On Fri, 2009-05-15 at 11:21 -0400, Hans-Christoph Steiner wrote:
> On May 15, 2009, at 4:09 AM, Roman Haefeli wrote:
> 
> >
> > Am 14.05.2009 um 22:14 schrieb Hans-Christoph Steiner:
> >
> >>
> >> On May 9, 2009, at 2:43 PM, Martin Peach wrote:
> >>
> >>> Roman Haefeli wrote:
> >>>> thanks for the info.
> >>>> On Fri, 2009-05-08 at 19:27 +0000, martin.peach at sympatico.ca wrote:
> >>>>>> 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.
> >>>> iirc, on linux at least, [comport] makes pd hang, _whenever_ the  
> >>>> other
> >>>> end disappears. i.e.:
> >>>> - pulling out the usb-cable, while the arduino is connected
> >>>> - turning off an rfcomm device
> >>>
> >>>
> >>> This looks like something related to the usb interface. I think  
> >>> pulling out an RS-232 cable has no effect, as the serial driver  
> >>> can only be closed by [comport]. With a usb adapter the usb driver  
> >>> can close the port.
> >>> I suspect that the comport_tick routine, which is called  
> >>> periodically to check for received characters, tries to access the  
> >>> serial port after the usb driver has closed it.
> >>> The non-Windows code in comport_tick looks like this:
> >>>
> >>> unsigned char   serial_byte;
> >>> fd_set          com_rfds;
> >>> int             count = 0;
> >>>
> >>> FD_ZERO(&com_rfds);
> >>> FD_SET(fd,&com_rfds);
> >>>
> >>> while((err=select(fd+1,&com_rfds,NULL,NULL,&null_tv)) > 0)
> >>> {
> >>>  err = read(fd,(char *) &serial_byte,1);
> >>>  outlet_float(x->x_data_outlet, (t_float) serial_byte);
> >>>  ++count;
> >>> }
> >>>
> >>> As you can see the select call only checks for the presence of  
> >>> received characters with com_rfds, and doesn't check the write or  
> >>> exception status. I suppose the select call should also check the  
> >>> exception fd_set, as the usb driver has no other way of informing  
> >>> [comport] that it has closed the port, it should have flagged it  
> >>> there.
> >>> (Although if the fd itself is no longer valid I don't know what to  
> >>> do...using non-existent file descriptors is a good way to crash Pd)
> >>>
> >>> ATM I only have 'legacy' RS-232 ports on my hardware so I can't  
> >>> test it, but I can change the code.
> >>>
> >>> Martin
> >>
> >>
> >> Ok, quick test shows a couple things:
> >>
> >> - just using [comport 1 115200] and then yanking the USB out causes  
> >> the crash, so no data needs to be sent to cause this.  This is with  
> >> a standard Arduino USB.
> >>
> >> - in the select() that you highlight, it is just testing before  
> >> reading, so I am guessing it would not be so useful to do a write  
> >> test if it is only going to read().
> >
> >
> > i can confirm this. when a [print] is connected to [comport] and  
> > after unplugging the usb cable, [comport] starts sending '0'  
> > messages with maximum rate.  so it seems, that it is bogusly  
> > receiving data.
> >
> > roman
> 
> Does it crash?  I just hooked up a print to my Arduino Stamp USB- 
> serial adapter and got nothing, and it doesn't crash either.  I find  
> that when disconnecting using an arduino, Pd usually crashes.
> 

sorry, i wasn't precise. it does not crash, but pd hangs (uses 100% cpu
and does not respond anymore). i interprete it as [comport] blocking pd
and going into an infinite loop, when the plug is pulled without prior
closing the port.

roman


	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de