thread: add notes on the behavior of futures
This commit is contained in:
parent
564dcf339a
commit
0d3d0d7d86
|
@ -6,3 +6,40 @@ Core engine support must be provided by a more primitive layer. The
|
||||||
more primitive layer must also provide `break-enabled-key` and special
|
more primitive layer must also provide `break-enabled-key` and special
|
||||||
handling for looking up a mark with that key so that an egine-specific
|
handling for looking up a mark with that key so that an egine-specific
|
||||||
default thread cell is produced.
|
default thread cell is produced.
|
||||||
|
|
||||||
|
Futures
|
||||||
|
-------
|
||||||
|
|
||||||
|
The implementation of futures here has different behavior than in the
|
||||||
|
original Racket implementation:
|
||||||
|
|
||||||
|
- Many more primitive operations are "safe" in the sense of allowing
|
||||||
|
a future to keep running in parallel. For example, operations on
|
||||||
|
mutable `eq?` and `eqv?` hash tables are safe, as are `equal?` and
|
||||||
|
`equal-hash-code`.
|
||||||
|
|
||||||
|
Any attempt to enter atomic mode at the level of Racket threads (as
|
||||||
|
implemented in this layer) is treated as unsafe and will block the
|
||||||
|
future. For example, attempting to use a port will invariably go
|
||||||
|
into atomic mode, so port operations are still "unsafe". Any
|
||||||
|
attempt to use a semaphore or channel will also involve atomic
|
||||||
|
mode, so those are unsafe in the sense of blocking a fututre.
|
||||||
|
|
||||||
|
Attempting to use any operation that depends on the current
|
||||||
|
continuation or the current thread will also block, as it must.
|
||||||
|
However, a continuation-sensitive operation can succeed if it is
|
||||||
|
delimited by a prompt that is shallower in the continuation than
|
||||||
|
the future's start; that's an improvement over the original Racket
|
||||||
|
implementation.
|
||||||
|
|
||||||
|
- A blocked future becomes permanently ineligible for running in
|
||||||
|
parallel. That is, if a future hits an unsafe operation, the future
|
||||||
|
won't switch to the main thread just long enough to perform the
|
||||||
|
operation and then switch back to parallel mode.
|
||||||
|
|
||||||
|
To put is another way, there are no operations that trigger a 'sync
|
||||||
|
logging output instead of a 'block output. That's main because so
|
||||||
|
many more operations are safe. A second reason is that the futures
|
||||||
|
implementation has a finer-grained view of a computation so that it
|
||||||
|
doesn't see operations like `fprintf`; it sees only `start-atomic`
|
||||||
|
as an unsafe step inside `fprintf`.
|
||||||
|
|
|
@ -18,6 +18,9 @@
|
||||||
"future-lock.rkt"
|
"future-lock.rkt"
|
||||||
"future-logging.rkt")
|
"future-logging.rkt")
|
||||||
|
|
||||||
|
;; See "README.txt" for some general information about this
|
||||||
|
;; implementation of futures.
|
||||||
|
|
||||||
(provide init-future-place!
|
(provide init-future-place!
|
||||||
futures-enabled?
|
futures-enabled?
|
||||||
future
|
future
|
||||||
|
|
Loading…
Reference in New Issue
Block a user