On Fri, 5 Oct 2001 09:49:20 +0100, Tim Waugh <twaugh@redhat.com> wrote:
>
> [ ... ]
>
> My one concern is the change that bumps the timeout back continually;
> it means that port->timeout means even less than before. It currently
> guarantees that the call will return in the same ball park as the
> timeout (I actually worked out the relationship once), but with your
> change it may never return (in theory).
>
> [ ... ]
>
Yeah, I'm concerned too, but I don't have a really good alternative to
solving this particular problem, which occurs when the printer stops
accepting data for a while and the FIFO still contains data. In this
case there appears to be no way to get the particular hardware I'm
working with the back off gracefully to let the upper levels deal with
things.
At least the code still responds to signals, which allows the user to
kill a connection. DOS/Windows (95 and 98, I can't say about the
other flavors) doesn't do even that much -- if a device stops
accepting data on the parallel port, you often have to disconnect the
cable to get the PC to recover.
One alternative I thought of would be to allow specifying an "infinite
retry" mode, either with a configuration parameter or with some sort
of setup call to the parport driver. I'd be happy to look into this
if I can get some guidance on what it ought to look like, and I'd be
happy to try other suggestions -- if/when I get the time, of course.
-- Dave Strauss
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Fri Oct 05 2001 - 08:47:47 EDT