Does printing require a separate process?

[Ron Kaplan]

I noticed that HARDCOPYW does an ADD.PROCESS around the printer's sending function, but SEND.FILE.TO.PRINTER just invokes the sending function directly.

They probably should do it the same way. Is there any current motivation for the complexity of the separate process in the generic code? If it is an important thing to do for particular classes of printers, maybe that should be in the printer-specific SEND method.

[Herb Jellinek]

Some printers (Epson MX-80, Xerox 4045, etc.) were attached directly to the D-machine via parallel port and were quite slow relative to, say, a networked laser printer.  Having client code block until the printer completed an entire document would have provided a terrible user experience.  I don't know why HARDCOPYW rather than SEND.FILE.TO.PRINTER called ADD.PROCESS.  Maybe it was an arbitrary choice.

Of course, a networked printer can take an arbitrarily long time to receive a document, so maybe we should just assume that print jobs should never block and put the ADD.PROCESS call in the most generic/high level hardcopy code.

            Herb

[Larry Masinter]

Interlisp-D uses the Interlisp spaghetti stack substrate to support multiple threads (aka Interlisp-D packages).

The "scheduler" is just a "round robin" implementation: when a thread calls BLOCK, it picks the next thread and gives control.

There's a monitor lock mechanism where a Interlisp process can 'lock' a resource so that other processes won't interfere.

code for separate processes has to be written so that: all IO goes through a separate window owned by the separate process. 

The RESETLST / RESETSAVE method of temporarily modifying a global resource, running something, and then putting it back isn't compatible with processes if there isn't separate storage allocated and being modified for each process touches the resource.

you should only add a process when the process can be done safely without modifying or relying on modifiable global resources.

--

https://LarryMasinter.net  https://interlisp.org

--
You received this message because you are subscribed to the Google Groups "Medley Interlisp core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispcore+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lispcore/dc2a93ec-00b4-4823-90c1-066688b412f7%40newscenter.com.

[Nick Briggs]

On Sep 28, 2025, at 16:17, 'Larry Masinter' via Medley Interlisp core <lisp...@googlegroups.com> wrote:

Interlisp-D uses the Interlisp spaghetti stack substrate to support multiple threads (aka Interlisp-D packages).

            ^processes not packages

The "scheduler" is just a "round robin" implementation: when a thread calls BLOCK, it picks the next thread and gives control.

There's a monitor lock mechanism where a Interlisp process can 'lock' a resource so that other processes won't interfere.

code for separate processes has to be written so that: all IO goes through a separate window owned by the separate process. 

The RESETLST / RESETSAVE method of temporarily modifying a global resource, running something, and then putting it back isn't compatible with processes if there isn't separate storage allocated and being modified for each process touches the resource.

you should only add a process when the process can be done safely without modifying or relying on modifiable global resources.

There are a lot of ALLOW.BUTTON.EVENTS and SPAWN.MOUSE calls scattered through the various hardcopy functions, so you're highly likely to have at least some extra processes.

The explicit ADD.PROCESS seems to be about deleting a scratch file once it has been sent to the printer,  if I'm reading that code correctly.  Since HARDCOPYW is called from a mouse event, and it is a pretty self-contained operation you would expect it to be asynchronous, but that's not what I would expect for SEND.FILE.TO.PRINTER -- and ti would probably break HARDCOPYW's cleanup if it were to become asynchronous, so I think the way it does it is OK.

-- Nick

--

https://LarryMasinter.net  https://interlisp.org

On Sun, Sep 28, 2025 at 9:46 AM Herb Jellinek <jell...@newscenter.com> wrote:

Some printers (Epson MX-80, Xerox 4045, etc.) were attached directly to the D-machine via parallel port and were quite slow relative to, say, a networked laser printer.  Having client code block until the printer completed an entire document would have provided a terrible user experience.  I don't know why HARDCOPYW rather than SEND.FILE.TO.PRINTER called ADD.PROCESS.  Maybe it was an arbitrary choice.

Of course, a networked printer can take an arbitrarily long time to receive a document, so maybe we should just assume that print jobs should never block and put the ADD.PROCESS call in the most generic/high level hardcopy code.

            Herb

On 9/27/25 8:12 PM, Ron Kaplan wrote:

I noticed that HARDCOPYW does an ADD.PROCESS around the printer's sending function, but SEND.FILE.TO.PRINTER just invokes the sending function directly.  

They probably should do it the same way.  Is there any current motivation for the complexity of the separate process in the generic code?  If it is an important thing to do for particular classes of printers, maybe that should be in the printer-specific SEND method.

--
You received this message because you are subscribed to the Google Groups "Medley Interlisp core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispcore+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lispcore/dc2a93ec-00b4-4823-90c1-066688b412f7%40newscenter.com.

--
You received this message because you are subscribed to the Google Groups "Medley Interlisp core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispcore+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/lispcore/CAKq15veQiSwvx%2B6JhXp_r1ix%2BOzx2b5%2BT9d8tNZrR3tJ-eXtfg%40mail.gmail.com.

[Ron Kaplan]

Actually, it appears that SPAWN.MOUSE is called only when the user is about to sweep out a region of the screen bitmap, to be given to the HARDCOPYW function.  So probably not relevant to the actual printing.

ALLOW.BUTTON.EVENTS may be a better clue.  It's only called in one place, in HARDCOPY.SOMEHOW,  before it decides how to print the window.  If there is no hardcopyfn, it does the window's bitmap through the branch that does the process.  Otherwise, it leaves it up to the hardcopyfn, and in the case of a Tedit window at least, it doesn't create a process, just calls the Tedit formatter.