[squeak-dev] Re: Delay time question

Robert F. Scheer rfscheer at speakeasy.net
Thu Feb 28 09:53:26 UTC 2008


On Thu, 2008-02-28 at 00:18 -0800, Andreas Raab wrote:
> Robert F. Scheer wrote:
> > Picture 5 serial lines.  Each has a packet of a few to a few dozen bytes
> > arriving every 20ms although they are not synchronous.  The data arrives
> > on time within a few microseconds every cycle and it must be captured.  
> > 
> > I was trying to use delays of around 15ms to prevent the Squeak i/o
> > processes from continuously tying up compute cycles trying to read the
> > serial lines when no data was expected.  Read a packet, delay 15ms, then
> > go into a tighter loop trying every 1ms until the packet was read.  
> > 
> > Now, I know this is a bad scheme.  Even a 1ms programmed delay could
> > become longer than 20ms sometimes.  So let's get rid of all programmed
> > delays inside the serial i/o loops.  
> 
> Ah. Now we are talking. What you want is the ability for a serial port 
> to issue an interrupt / signal a semaphore so that your waiting process 
> gets woken up when something happens. The way to do this is by fixing 
> the (very, very naive) serial port primitives to add something that 
> allows you to signal a semaphore upon data availability. There are 
> examples for this kind of thing in other plugins (like the socket or 
> async file plugin).
> 
> Also, I vaguely remember that John had built a better serial port plugin 
> (don't remember where I saw this but I'm sure he'll chime in) which may 
> very well support this out of the box.
> 
> > I probably don't understand the primitive serial methods well enough.
> > They seem not to block while awaiting input so that requires
> > continuously looping to read.  Is there a blocking method?
> 
> There isn't. Since Squeak doesn't use native threads internally (instead 
> it uses so-called "green threads") a blocking read would block the 
> entire VM and completely defeat the purpose of a blocking read. That's 
> why all such primitives are designed to simply signal a semaphore so 
> that the process in squeak just sits there doing something like:
> 
>    dataArrived := Semaphore new.
>    self registerSemaphoreForSignallingData: dataArrived.
>    [true] whileTrue:[
>       dataArrived wait.
>       self processData.
>    ].
> 
> etc.
> 
> Cheers,
>    - Andreas
> 
> 

Yes, that's what I need.  Unfortunately being a Squeak newbie and having
one month till competition, this looks like an insurmountable gap to me
atm.  But if it existed, I'd be in heaven.

Thanks for the analysis.

- Robert




More information about the Squeak-dev mailing list