Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • A asdf
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 62
    • Issues 62
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 20
    • Merge requests 20
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • asdf
  • asdf
  • Issues
  • #62
Closed
Open
Issue created Mar 15, 2021 by Eric Timmons@etimmonsOwner

Implementation Specific Behavior for LAUNCH-PROGRAM Output Streams

I was trying to use launch-program to programmatically interact with another process's REPL and stumbled across some behavior that is implementation dependent. I was wondering if we should note it in the doc string and/or provide some mechanism to smooth over the differences.

When passing non fd-backed streams to :output or :error-output, the implementation can't in general pass that stream directly the child process to write to. Instead, the parent has to set up a pipe and shuffle bits from the pipe to the stream where you want the output to go. SBCL doesn't shuffle those bits until you wait-process or serve-event. ECL spawns a new thread for each process that constantly does the shuffling. I haven't dug around in CCL internals yet, but it appears to behave as ECL in my tests.

In my case, I was writing error-output to a non fd-backed stream and using :stream for the output. On SBCL, when the child produced over 64k bytes of data on error-output (the default pipe buffer size on my setup), the child process would freeze since it couldn't write anything else. I'm currently working around this by writing the error output to a temporary file and reading it when done.

I'm honestly not sure if smoothing over the difference is going to be worth the effort. If we did, the solution would likely be either a function that the user has to call periodically (ugh) or spawn a new thread that handles it (even more ugh since uiop would have to know about threads then).

But a warning might save someone else from pulling out their hair like I did.

Assignee
Assign to
Time tracking