Threads

Files: thread.ss, threadu.ss, threadr.ss, threads.ss, threadc.ss
Signature: mzlib:thread^
Unit: mzlib:thread@

(consumer-thread f [init]) PROCEDURE

Returns two values: a thread descriptor for a new thread, and a procedure with the same arity as f. When the returned procedure is applied, its arguments are queued to be passed on to f, and void is immediately returned. The thread created by comsumer-thread dequeues arguments and applies f to them, removing a new set of arguments from the queue only when the previous application of f has completed; if f escapes from a normal return (via an exception or a continuation), the f-applying thread terminates.

The init argument is a procdure of no arguments; if it is provided, init is called in the new thread immediately after the thread is created.

(merge-input a b) PROCEDURE

Accepts two input ports and returns a new input port. The new port merges the data from two original ports, so data can be read from the new port whenever it is available from either original port. The data from the original ports are interleaved. When EOF has been read from an original port, it no longer contributes characters to the new port. After EOF has been read from both original ports, the new port returns EOF. Closing the merged port does not close the original ports.

(semaphore-wait-multiple semaphore-list [timeout allow-break?]) PROCEDURE

Waits on all of the semaphores in semaphore-list in parallel until a semaphore-wait succeeds for one of the semaphores. The result is the semaphore for which semaphore-wait succeeded, and the internal counts for the other semaphores remains unchanged.

If a non-negative number timeout is supplied, semaphore-wait-mulitple will return #f after (at least) timeout seconds if no semaphores become available. The default timeout is #f, in which case semaphore-wait-mulitple never returns #f.

The allow-break? argument indicates whether to enable user breaks while waiting on the semaphores. If user breaks are enabled on entry to semaphore-wait-mulitple, then semaphore-wait-mulitple can be broken as well. Like semaphore-wait/enable-break, will either return a value or raise an exception without changing the status of any semaphores. However, in this case it is possible for a user break to occur after semaphore-wait-mulitple returns a value but before that value is returned to a calling context. Therefore, the only way to gurantee that a successful semaphore-wait is not lost is to disable breaks around the waiting context and pass a true value for allow-break?. The default value is #f.

(with-semaphore s thunk) PROCEDURE

Calls semaphore-wait on s, then invokes thunk with no arguments, and then calls semaphore-post on s. The return value is the result of calling thunk.