Commit 77023aeaba made the reference from a custodian-managed
value to the custodian weak, and that could cause a crash in
certain shutdown cases.
Relevant to #2867
Just bumping the version number here to make sure the improved
`call/cc` is used. The improvement saves about 10% on ctak by avoiding
a layer of closure allocation.
Refactor to move some composable-continuation support out of the
way of prompts, and add a shortcut for simple composition cases.
Also, fix stack traces with continuation barriers and composable
composition, which could show sections of a trace duplicated.
For Racket CS, weaken references from managed objects to managing
custodians. Otherwise, a custodian with any managed values cannot
be GCed. Also, fix `collect-garbage` call that is triggered by
a memory-limit shutdown to happen after the current thread
(likely shutdown) is swapped out.
For traditional Racket, fix custodian shutdown on a memory-limited
custodian so that it is unregistered as having a limit.
Lift and delay serialization for non-serializable literals when
using `compile`. Just `compile`ing such an expression is ok, but
it reports an error if there's an attempt to serialize (by printing)
the compiled value.
This improvment also brings Racket CS much more in line with
traditional Racket on the kinds of values that it is willing to
serialize. For example, non-prefab structures no longer serialize
(where deserializing in a new Racket run would produce an instance of
a distinct structure type). The exception type and error message also
now matches traditional Racket.
The improvement relies on a new argument to `s-exp->fasl` for handling
errors.
Also, adjust a memory-limit test that wasn't checking behavior as
intended and that wasn't consistent with a Racket CS improvement over
traditional Racket.
A base type of `_gcpointer` works ok for traditional Racket as a kind
of "maybe it's GCable, so treat it that way just in case". That
approach doesn't work for Racket CS, where `_gpointer` has to mean
"definitely GCable memory". Although the difference is unfortunate,
making Racket CS base `(_bytes o <n>)` on `_pointer` is consistent
with the way plain `_bytes` is like `_pointer` in Racket CS and like
`_gcpointer` in traditional Racket.
Some synchronization built into `close-output-port` seems unnecessary
on modern Windows (NT and up). An extra manager thread is needed for a
anonymous pipe for "write ready?" purposes, but not to buffer output.
The Windows documentation is not entirely clear on this point, but
experiments suggest that modern anonymous pipes behave in the obvious
way.
Meanwhile, adjust the io layer used by Racket CS with the
synchronization that would be needed for Windows 95. This adjustment
is questionable, because it doesn't seem likely that we'll ever go
back that far with Racket CS. But the rktio interface to support
flushing synchronization might somehow be needed in a future setting,
or mabe it will turn out that I'm wrong about pipe buffers.
Avoid a continuation frame and layer of thunks that was in place for
checking for breaks just after applying a continuation. Instead, we
install just the continuation marks and check for breaks before
actually jumping; the break checker can't tell the difference, since
marks are the only way for it to check the continuation. This
improvement cust about 40% of the time for simple continuation capture
and application.
A misplaced `wrap-evt` could allow the result from `sync` on
a log receiver to be an opaque event, instead of a vector.
In other cases, a differently misplaced `wrap-evt` could also cause an
internal instance of `control-state-evt` to not be unregistered
correctly.
The solution to both problems is to add a wrapper procedure to
`control-state-evt`.
Closes#2664
Repair problems with asynchronous callbacks for futures and for
foreign callbacks. Asynchronous callbacks are used for future "sync"
operations, like `hash-set!`, that run must in a place's main thread
(as of commit f574583907).
Separately, synchronization to clean up future threads used a `ping?`
flag in a backwards sense, and it also treated a record as a box.
These problems could cause place termination to hang.
Related to #2725
The `math` library relies on this working right, since MPFR is
normally not compiled as thread-safe.
Also, fix some locking/interrupt/atomicity problems with async
callbacks generally.
When `sync` or `place-channel-get` is used on a place channel whose
other end has been GCed, then the blocking thread should also be
GCable. The `sync` case didn't work because the implementation uses
`replace-evt`. Change `sync` so that it can recognize asynchronous
`replace-evt`s in the same way as semaphores and channels (which is
more than traditional Racket offers).
When a place terminates, it was directly accessing its parent's
custodian. Prior support for cross-place uses of a hash table
probably helped hide this problem previously.
Although extremely unlikely, it was possible for multiple Racket
threads operating on the same scopes to race on a multi-scope's table
mapping phase levels to scopes.
Also, for some some mutable hash tables that will be shared across
places as read-only in Racket CS, make sure they are definitely set up
for iteration.
An `eq?`-based hash table in the implementation of custodians was
still shared across threads.
Also, taking the global lock at the Rumble level did not disable
interrupts. Since sometimes the lock is taken with interrupts
disabled, threads could potentially deadlock by not having an order.
Fix the problem by disabling interrupts before taking the lock.
Use the pseudo-random generator API that is now available from Chez
Scheme. While the generator can be written in Scheme, the lack of
unboxed floating-point arithmetic unfortunately makes it about 6 times
as slow as a built-in implementation. That difference is significant
when `sync` uses `random` for fair scheduling.
The `time-apply` function was measuring thread time instead of proecss
time. While thread time would be more useful in many cases, it's meant
to report process time.
Mutable `eq?`- and `eqv?`-based hash tables were formerly guarded by a
lock that made them safe for Scheme threads (i.e., OS-level threads).
In particular, that futures could concurrently access hash tables. But
the cost of that lock appears to be too high for such a rarely-used
capability.
Switching `eq?`- and `eqv?`-based hash tables so that they're safe
only for Racket threads means that the lock on a hash table can be
much cheaper. A lock is still needed to because the Rumble layer adds
extra fields for iteration. In the specific case of `hash-ref` on
`eq?`-based tables, however, the lock can be ignored, which makes one
of the most common `hash-ref`s much faster.
Overall, `hash-ref` on a mutable `eq?`-based hash table is now 4-5
times as fast, which makes it about twice as fast as traditional
Racket's `hash-ref`. A `hash-set!` operation is about twice as fast as
before, which puts it on par with traditional Rackets `hash-set!`. The
`hash-ref` improvement makes `send` about twice as fast as before in
Racket CS, making it a little faster than traditional Racket.
Since futures can no longer concurrently access `eq?`- and
`eqv?`-based hash tables, they have to synchronize with the main
thread for access. Racket CS had avoided the "sync" action on futures
that traditional Racket sometimes uses, but this change introduces
sync actions to Racket CS, since it's appropriate for accessing
mutable `eq?`- and `eqv?`-based hash tables.
Adjust the internal engine protocol to avoid a jump from a starting
engine (representing a thread) to a scheduler outside of an engine
to a target engine (for a swapped-ni thread); instead, jump from the
first engine to the target, effectively running the scheduler within
the starting engine's context.
In a file-stream output port or TCP output port, when flushing
encounters an error, consistently discard bytes in the buffer. This
isn't the obviously right choice, but otherwise a future flush attempt
(including one triggered by trying to close the port or one triggered
by a plumber) will likely just fail again, which is probably worse
than dropping bytes.
Also, fix related problems/inconsistencies.
Overall changes:
* For traditional Racket, discard bytes in a TCP port when flushing
fails.
* For Racket CS, discard bytes in file-stream and TCP output ports
when flushing fails.
* For traditional Racket, when a file-stream port flush is
interrupted by an asynchronous break, *don't* discard buffered
bytes.
* For Racket CS, don't register TCP ports with the current plumber.
When the original compiler handler is called with a true second
argument, then the resulting module is not serializable. Improve
detecting and reporting of the misuse.
The error is phrase in terms of linklets, which is not ideal, but
that's the level where the error can be detected. Abusing the original
compile handler in this way is not easy, though, so maybe this
improvement is enough.
Adds an additional line to the error message that is raised when a
required module provides a binding that is already provided by another
required module. The additional line displays the name of the first
module that provides the binding.
The error before this change:
tmp/c.rkt:4:9: module: identifier already required
at: x
in: "b.rkt"
location...:
tmp/c.rkt:4:9
and after:
tmp/c.rkt:4:9: module: identifier already required
at: x
in: "b.rkt"
also provided by: "a.rkt"
location...:
tmp/c.rkt:4:9
Add text of MIT and Apache v2 licenses.
Add initial CONTRIBUTING.md file which specifies contribution license.
Add COPYRIGHT.txt file which specifies the license and lists some
external components.
The LGPL license stays in its current location to avoid having to
modify the build right now.
The Mac OS 10.15 headers include a `#pragma` just before the closing
`;` of a `struct` declaration. That confuses poor xform. Handle this
special case by detecting it and swapping the order of the `#pragma`
and `;`.
If a source file name lacks an extension, then the pkg-step would get
confused trying to convert a ".zo" name back to a source name. The
original name is not really needed, anyway.
When a reference to a local variable is updated with the scopes of its
binding in a fully expanded program, remove the syntax-original
property if the original reference had macro-intrudction scopes.
Closes#2820
Trying to be more helpful about the thread running an `unsafe-poller`
callback gets in the way of making the process sleep when multiple
threads are blocked on unsafe pollers.
Closes#2833
Prune some `with-continuation-marks` forms that aren't observable
(because the body is simple enough that it won't inspect marks). More
significantly, specialize `with-continuation-marks` forms to indicate
when the current frame is known to have no marks and to indicate
when tthe key expression is known to produce a non-impersonator.
Since `#%app` (used where an applicable structure might show up)
injects its own `procedure?` test and makes sure that that a procedure
is returned to the function position of the application, use `#3%$app`
to make Chez Scheme suppress a redundant `procedure?` check for the
appliction.
It's not clear that a thread can be descheduled without the current
thread's work counting as progress, but a descheduled thread certainly
shouldn't coun as a no-progress scheduled thread.
Only one instance of each callback is needed. Allowing them to pile up
is inefficient, and possibly it can trigger a reaction that causes
even more to pile up.
(for ([x (in-value 1 2)]) x)
should raises a run time error, not a syntax error.
Fix similar error in other in-something macros.
Fix name of in-directory, when used as a function outside a for.
Unfortunately, MZ_NORETURN spec is causing a few problems - see #2808
It would be great to fix these but due to lack of time, this is a
workaround that should keep things working until all supported
configurations accept MZ_NORETURN properly.
