2

Is the readable file event triggered by a channel becoming readable, or by it being readable? In a file event handler, do I have to read all available input to get a new event triggered in the future? Or can I read only 1 character and return, and if there was more input, my handler will automatically be called again directly? Or not directly, but rather put at the end of the event queue, so this would be the preferred way to do it (maybe not just 1 character but for example 1 line) to prevent one stream from blocking the entire program?

potrzebie
  • 1,768
  • 1
  • 12
  • 25

1 Answers1

3

It is triggered by a channel being readable, so you can read only a part of input (or read nothing occasionally, being sure that the handler will be called again). However, reading all available input is better for performance (not necessarily all available bytes: if you read line by line, do gets until it returns -1 for fblocked condition).

The sign of input being exhausted is the true value of [fblocked $channel]. That's why the use case with gets and incomplete line of input is possible: even though the channel is technically readable, just not getsable, the event doesn't fire again until new data arrive.

Anton Kovalenko
  • 20,999
  • 2
  • 37
  • 69
  • 2
    Technically, it's triggered by becoming readable but Tcl fakes events when it has buffered data available. You don't have to worry about the difference unless you're writing a channel driver (which most people are sensible enough to not do). – Donal Fellows Jan 28 '13 at 14:38
  • No, `select` as such is level-triggered: if you don't drain a readable file descriptor, the next `select` will notify on readability immediately. Buffering takes some data away from `select`, so in return Tcl has to "fake" events that select would generate if there were no buffering. But select *would* generate them just as well in a similar situation. – Anton Kovalenko Jan 29 '13 at 10:43