Re: [TCLCORE] TIP #361: Releasing Channel Buffers

[<tc...@us...>]

On Wed, Feb 10, 2010 at 11:32:29PM +0100, Alexandre Ferrieux wrote:
> On 2/10/10, Alexandre Ferrieux <ale...@gm...> wrote:
> >
> > Bottom line: I think your [chan clear] proposal, whatever the return
> >  value, covers all cases, as does the [fconfigure] approach. So now I'm
> >  listening to opinions about this "imperative vs fconfigure" question.
> >  I'm ready to implement either.
> 
> Clarification: of course the [fconfigure] still doesn't allow for
> discarding in mid-life, so the question is more precisely, which one
> is preferred among:
> 
>   (a) Simplicity of [exit] with an [fconfigure -fastclose 1] at the
> beginning, no way to express short writes.
> 
>   (b) Expressivity of short writes with [puts;chan clear] at the cost
> of a slightly more complex loop over existing channels for a timely
> exit.
> 
> -Alex

I prefer (b) since it allows you to work with channels that may come
back to life without necessitating a close-open sequence. Yes, it is a
little more complex but that tends to be the case with additional
flexibility.

Ex.
- the other side stops reading for an extended period of time
- you clear the channel buffer and setup a writable handler
- when your handler is called you can reset the other devices state with a
  'sync' character(s) and continue with the conversation
- yes, it's not common but I have some serial devices that end
  pausing/freezing occasionally then spewing and/or consuming garbage
  but we can "reset" the conversation with a sync char

LOL, that's right I get to work with lots O buggy devices/software..
yay!

The simpler case is it stops reading, I clear the channel buffer and
send a sync char without needing to wait for my writable handler to be
called.

But I'll bet someone could persuade me choose (a) with good
justification.

Wayne