13.1.10 More Port Constructors, Procedures, and Events

13.1.10.1 Port String and List Conversions

Changed in version 6.8.0.2 of package base: Added the #:close? argument.

Changed in version 6.8.0.2 of package base: Added the #:close? argument.

Changed in version 6.8.0.2 of package base: Added the #:close? argument.

Changed in version 6.8.0.2 of package base: Added the #:close? argument.

The port passed to proc is like the one created by open-output-string, except that it is wrapped via dup-output-port, so that proc cannot access the port’s content using get-output-string. If control jumps back into proc, the port continues to accumulate new data, and call-with-output-string returns both the old data and newly accumulated data.

(call-with-output-string

(lambda (p) (parameterize ([current-output-port p])

(proc))))

(call-with-output-bytes

(lambda (p) (parameterize ([current-output-port p])

(proc))))

(parameterize ([current-input-port (open-input-string str)])

(proc))

(parameterize ([current-input-port (open-input-bytes str)])

(proc))

13.1.10.2 Creating Ports

The name argument determines the name as reported by object-name for the returned input port.

See also merge-input, which interleaves data from multiple input ports as it becomes available.

Changed in version 6.90.0.19 of package base: Added the name argument.

The read-in, close, get-location, count-lines!, init-position, and buffer-mode procedures are the same as for make-input-port.

The fast-peek argument can be either #f or a procedure of three arguments: a byte string to receive a peek, a skip count, and a procedure of two arguments. The fast-peek procedure can either implement the requested peek, or it can dispatch to its third argument to implement the peek. The fast-peek is not used when a peek request has an associated progress event.

The buffering? argument determines whether read-in can be called to read more characters than are immediately demanded by the user of the new port. If buffer-mode is not #f, then buffering? determines the initial buffer mode, and buffering? is enabled after a buffering change only if the new mode is 'block.

If on-consumed is not #f, it is called when data is read (or committed) from the port, as opposed to merely peeked. The argument to on-consumed is the result value of the port’s reading procedure, so it can be an integer or any result from read-in.

Bytes are consumed from in only when they are consumed from the returned port. In particular, peeking into the returned port peeks into the original port.

If in is used directly while the resulting port is also used, then the limit bytes provided by the port need not be contiguous parts of the original port’s stream.

The limit argument determines the maximum capacity of the pipe in bytes, but this limit is disabled if special values are written to the pipe before limit is reached. The limit is re-enabled after the special value is read from the pipe.

The optional in-name and out-name arguments determine the names of the result ports.

The optional buffer-limit argument limits the number of bytes to be buffered from a-in and b-in, so that the merge process does not advance arbitrarily beyond the rate of consumption of the merged data. A #f value disables the limit. As for make-pipe-with-specials, buffer-limit does not apply when a special value is produced by one of the input ports before the limit is reached.

See also input-port-append, which concatenates input streams instead of interleaving them.

The optional name argument is the name of the resulting port. The skip argument is the port initial skip count, and it defaults to 0.

The resulting port’s initial position (as reported by file-position) is (- init-position 1), no matter the position of in.

The resulting port supports buffering, and a 'block buffer mode allows the port to peek further into in than requested. The resulting port’s initial buffer mode is 'block, unless in supports buffer mode and its mode is initially 'none (i.e., the initial buffer mode is taken from in when it supports buffering). If in supports buffering, adjusting the resulting port’s buffer mode via file-stream-buffer-mode adjusts in’s buffer mode.

For example, when you read from a peeking port, you see the same answers as when you read from the original port:

Beware that the read from the original port is invisible to the peeking port, which keeps its own separate internal counter, and thus interleaving reads on the two ports can produce confusing results. Continuing the example before, if we read three more characters from the peeking port, we end up skipping over the 456 in the port (but only because we disabled buffering above):

If we had left the buffer mode of a-peeking-port alone, that last read-string would have likely produced "456" as a result of buffering bytes from an-original-port earlier.

Changed in version 6.1.0.3 of package base: Enabled buffering and buffer-mode adjustments via file-stream-buffer-mode, and set the port’s initial buffer mode to that of in.

If error-bytes is provided and not #f, then the given byte sequence is used in place of bytes from in that trigger conversion errors. Otherwise, if a conversion is encountered, enc-error is called, which must raise an exception.

If close? is true, then closing the result input port also closes in. The name argument is used as the name of the result input port.

In non-buffered mode, the resulting input port attempts to draw bytes from in only as needed to satisfy requests. Toward that end, the input port assumes that at least n bytes must be read to satisfy a request for n bytes. (This is true even if the port has already drawn some bytes, as long as those bytes form an incomplete encoding sequence.)

If error-bytes is provided and not #f, then the given byte sequence is used in place of bytes that have been sent to the output port and that trigger conversion errors. Otherwise, enc-error is called, which must raise an exception.

If close? is true, then closing the result output port also closes out. The name argument is used as the name of the result output port.

The resulting port supports buffering, and the initial buffer mode is (or (file-stream-buffer-mode out) 'block). In 'block mode, the port’s buffer is flushed only when it is full or a flush is requested explicitly. In 'line mode, the buffer is flushed whenever a newline or carriage-return byte is written to the port. In 'none mode, the port’s buffer is flushed after every write. Implicit flushes for 'line or 'none leave bytes in the buffer when they are part of an incomplete encoding sequence.

The resulting output port does not support atomic writes. An explicit flush or special-write to the output port can hang if the most recently written bytes form an incomplete encoding sequence.

When the port is buffered, a flush callback is registered with the current plumber to flush the buffer.

The new port is initialized with the port read handler of in, but setting the handler on the result port does not affect reading directly from in.

The new port is initialized with the port display handler and port write handler of out, but setting the handlers on the result port does not affect writing directly to out.

The line and column values are used only if line counting is enabled for in and for the resulting port, typically through port-count-lines!. The column value determines the column for the first line (i.e., the one numbered line), and later lines start at column 0. The given position is used even if line counting is not enabled.

When line counting is on for the resulting port, reading from in instead of the resulting port increments location reports from the resulting port. Otherwise, the resulting port’s position does not increment when data is read from in.

If close? is true, then closing the resulting port also closes in. If close? is #f, then closing the resulting port does not close in.

The name argument is used as the name for the resulting port; the default value keeps the same name as in.

If count-lines! is supplied, it is called when line counting is enabled for the resulting port. The default is void.

If close? is true, then closing the resulting port also closes in.

If close? is true, then closing the resulting input port also closes in.

13.1.10.3 Port Events

If attempting to read from in raises an exception during a synchronization attempt, then the exception may be reported during the synchronization attempt, but it will silently discarded if some another event in the same synchronization is selected or if some other event raises an exception first.

Changed in version 7.5.0.3 of package base: Changed handling of read errors so they are propagated to a synchronization attempt, instead of treated as unhandled errors in a background thread.

Bytes are read from the port if and only if the event is chosen in a synchronization, and the returned bytes always represent contiguous bytes in the port’s stream.

The event can be synchronized multiple times—event concurrently—and each synchronization corresponds to a distinct read request.

The in must support progress events, and it must not produce a special non-byte value during the read attempt.

Exceptions attempting to read from in are handled in the same way as by eof-evt.

The bstr may be mutated any time after the first synchronization attempt on the event and until either the event is selected, a non-#f progress-evt is ready, or the current custodian (at the time of synchronization) is shut down. Note that there is no time bound otherwise on when bstr might be mutated if the event is not selected by a synchronzation; nevertheless, multiple synchronization attempts can use the same result from read-bytes!-evt as long as there is no intervening read on in until one of the synchronization attempts selects the event.

Exceptions attempting to read from in are handled in the same way as by eof-evt.

A line is read from the port if and only if the event is chosen in a synchronization, and the returned line always represents contiguous bytes in the port’s stream.

Exceptions attempting to read from in are handled in the same way as by eof-evt.

If pattern does not require a start-of-stream match, then bytes skipped to complete the match are read and discarded when the event is chosen in a synchronization.

Bytes are read from the port if and only if the event is chosen in a synchronization, and the returned match always represents contiguous bytes in the port’s stream. If not-yet-available bytes from the port might contribute to the match, the event is not ready. Similarly, if pattern begins with a start-of-stream ^ and the pattern does not initially match, then the event cannot become ready until bytes have been read from the port.

The event can be synchronized multiple times—even concurrently—and each synchronization corresponds to a distinct match request.

The in port must support progress events. If in returns a special non-byte value during the match attempt, it is treated like eof.

Exceptions attempting to read from in are handled in the same way as by eof-evt.

13.1.10.4 Copying Streams

If opening the converter fails, the exn:fail exception is raised. Similarly, if a conversion error occurs at any point while reading from in, then exn:fail exception is raised.

This function is often called from a “background” thread to continuously pump data from one stream to another.

If multiple outs are provided, data from in is written to every out. The different outs block output to each other, because each block of data read from in is written completely to one out before moving to the next out. The outs are written in the provided order, so non-blocking ports (e.g., file output ports) should be placed first in the argument list.