Centronics (was Re: Threads (was Re: MSI interrupts))

On Thu, 03 Apr 2025 15:00:53 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:

Terje Mathisen <terje.mathisen@tmsw.no> writes:
>

For instance, consider Unix/POSIX `open`: from an API
perspective this simply maps a symbolic file path name to a file
descriptor that can subsequently be used to perform IO on the
named file.  While it is well-known that the interface is
defined so that it can block opening some kinds of devices, for
example, some terminal devices until the line is asserted, that
is not the usual case, and noteably `open` does no IO on the
file itself.  So generally, most programs would expect that it
has no reason to block.

>
The one case where open was a problem on traditional unix was
for line printers.    The open of /dev/lp could block if the
printer (on a centronics port) was not-ready.   And it was
an uninterruptable block, even SIGKILL was blocked.

To be clear: was this an actual Centronics (parallel) port, or just a
standard parallel port talking to a printer that uses a Centronics
connector?


I still have a couple of working laser printers that have Centronics
connectors. They talk to standard parallel ports via parallel <->
Centronics cables.

They currently are hosted on a Windows machine ... but with the
imminent demise of Win10, I plan to move them to Linux.  But I don't
want software (print/queue daemon?) hanging if a printer happens to be
turned off.

I have long wanted to retire the parallel ports, but I have never been
able to get USB <-> Centronics working reliably: when a printer goes
to sleep on USB, it never gets woken up again.  I have tried adapters
and cables from different vendors, but nothing has worked reliably and
I have never been able to determine where the problem lies. No amount
of futzing with server-side USB settings seems to help, and there is
nothing for it on the printer side other than totally disabling sleep
mode.