How to read stdin (and write to stdout)?

[guest271314]

In QuickJS we can do something like this read from stdin, open a new process and pipe the output from the process to stdout, in this case to Chromium browser using Native Messaging, with something like

 #!/usr/bin/env -S ../native-messaging-quickjs/qjs --std
// QuickJS Native Messaging host
// guest271314, 5-6-2022

function getMessage() {
  const header = new Uint32Array(1);
  std.in.read(header.buffer, 0, 4);
  const [length] = header;
  const output = new Uint8Array(length);
  std.in.read(output.buffer, 0, length);
  return output;
}

function sendMessage(json) {
  std.out.write(Uint32Array.of(json.length).buffer, 0, 4);
  std.out.puts(json);
  std.out.flush();
  std.gc();
}

function main() {
  const message = getMessage();
  const size = 1764;
  const data = new Uint8Array(size);
  const pipe = std.popen(
    JSON.parse(String.fromCharCode(...message)),
    'r'
  );
  while (pipe.read(data.buffer, 0, data.length)) {
    sendMessage(`[${data}]`);
    pipe.flush();
    std.gc();
  }
}

try {
  main();
} catch (e) {
  std.exit(0);
}

I'm checking out workerd for the server and streams capability, so I can use fetch() on any Web site and stream captured raw PCM to the browser where that audio is written to a MediaStreamTrackGenerator that can be recorded and streamed to any other peer with WebRTC.

Here I suspect workerd is not intended to be used to spawn child processes. That is fine. I can use QuickJS to launch workerd, and the child process that I can pipe to workerd to serve as a ReadableStream in a Response.

I browsed through /io yet didn't locate any examples of reading from stdin.

Kindly direct me to where to read about or explain how to in code read input from stdin so I can write that data to a ReadableStream in workerd environment.

[guest271314]

What I tried so far was

1. User on arbitrary Web page sinals via gesture or programmatically to connect to QuickJS Native Messaging host;

2. Start workerd server, create a ReadableStream to write to and send to client;

3. On message event from Native Messaging hosy post the JSON as Uint8Array to workerd server, then write the data to the ReadableStream;

4. Serve the ReadableStream to the client via fetch(), and abort terminate all processes.

Streams are transferable on Chromium and Chrome, and Firefox now.

I achieved 1-3 then encountered these errors.

./workerd-linux-64 --verbose serve config.capnp
workerd/io/worker.c++:1677: info: uncaught exception; 
source = Uncaught (in promise); 
exception = Error: Cannot perform I/O on behalf of a different request. 
I/O objects (such as streams, request/response bodies, and others) created 
in the context of one request handler cannot be accessed from a different 
request's handler. This is a limitation of Cloudflare Workers which allows us 
to improve overall performance.
workerd/io/io-context.c++:381: info: 
uncaught exception; exception = workerd/jsg/_virtual_includes/jsg/workerd/jsg/value.h:1347:
 failed: jsg.Error: Cannot perform I/O on behalf of a different request. I/O 
objects (such as streams, request/response bodies, and others) created in the 
context of one request handler cannot be accessed from a different request's handler. 
This is a limitation of Cloudflare Workers which allows us to improve overall performance.
stack: ./workerd-linux-64@1948b90 ./workerd-linux-64@1949759 ./workerd-linux-64@1814c10 ./workerd-linux-64@1815240
workerd/server/server.c++:2225: error: Uncaught exception: 
workerd/jsg/_virtual_includes/jsg/workerd/jsg/value.h:1347: failed: remote.jsg.Error: 
Cannot perform I/O on behalf of a different request. I/O objects
 (such as streams, request/response bodies, and others) created in the context
 of one request handler cannot be accessed from a different request's handler. 
This is a limitation of Cloudflare Workers which allows us to improve overall performance.
stack: ./workerd-linux-64@1948b90 
./workerd-linux-64@1949759 
./wo ./workerd-linux-64@1814c10 
./workerd-linux-64@1815240 
./workerd-linux-64@1816080 
./workerd-rkerd-linux-64@1814c10
./workerd-linux-64@1815240
./workerd-linux-64@1816080 
./workerd-linux-64@18166a0 
./workerd-linux-64@1d11790 
./workerd-linux-64@1d142a0

[kentonv]

Hi @guest271314,

workerd is a server-oriented runtime. It is not designed to be run as a CLI command and there is no way for a Worker to interact directly with stdin/stdout. Sorry, but this is probably not a good use case for workerd.

[guest271314]

Technically you already have stdin and stdout in the form of requests and responses.

I don't get why we can't actually stream.

Whether or not a user decides to hold the ReadableStream from one request and serve it to another response should be user-defined, not restricted by the application.

It is no different from receiving a file upload, writing the contents to disk, then fetching those contents and serving them.

You folks shouldn't be arbitrarily restricting capabilities that should be exposed user options. It's up to the user if they want to sacrifice what workd authors consider "performance" for capabilities.

[lmeyer743]

Just use Deno? It's more suited for your use cases.

[guest271314]

Just use Deno? It's more suited for your use cases.

I don't think so. Deno's HTTPS server runs at a constant 85-95% CPU when streaming https://gist.github.com/guest271314/a8eace7cb17019a8833a28c297759072, and for some reason is allocating 5GB VSZ https://gist.github.com/guest271314/93587ee12d61154fb26954e17f87e160.

Bun's server doesn't really stream oven-sh/bun#1886.