Closed jacob-hughes closed 3 years ago
At first I wasn't sure about this, but having looked a bit more carefully, I now think it's OK. We could, perhaps, change the Cell
in SOMStack
to AtomicUsize
but the practical effect would be zero. I think this is OK as-is.
bors r+
Build succeeded:
Yes I think so. Cell
doesn't implement Sync
, so even though the SOMStack
can be passed between threads, its data can't be accessed by another thread. An AtomicUsize
(or Mutex
) would work if we wanted its access to be synchronised, but it looks like it's only used by the main-thread at the moment.
yksom is single threaded so no problem there!
This updates various places in yksom to work after the following breaking changes to libgc:
Gc<T>
can no longer be mutably dereferenced, so the places in yksom which relied on this have been updated to use interior mutability instead.Gc<T>
now requiresT: Send
, so theObj
andArray
traits needed updating with this constraint also.Please can you pay special attention to the changes I've made in
UpVars
. The first couple of times I'd tried this, I had broken theblock.som
andescape{n}.som
tests. I seem to have got this working now, I'd got very confused over whether in places I needed to be taking the on-stack-reference, or theusize
field insideVal
.