You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ZeroCopyBuf wraps a reference to a backing store that is potentially shared with an ArrayBuffer object, and thus is only safely accessible from one thread. Therefore, ZeroCopyBuf, and MagicBuffer which wraps it, must not be Send or Sync – yet they are both. In fact, ZeroCopyBuf unsafely implements Send, even though that is not needed – which seems to be a holdover from previous iterations of this API.
Once denoland/deno#12678 is solved, it might be possible to allow a way safely send ZeroCopyBuf values, as long as their backing store was created for a SharedArrayBuffer – but implementing Send directly on ZeroCopyBuf would still not be sound. We can tackle this when the time comes.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
ZeroCopyBuf
wraps a reference to a backing store that is potentially shared with anArrayBuffer
object, and thus is only safely accessible from one thread. Therefore,ZeroCopyBuf
, andMagicBuffer
which wraps it, must not beSend
orSync
– yet they are both. In fact,ZeroCopyBuf
unsafely implementsSend
, even though that is not needed – which seems to be a holdover from previous iterations of this API.Once denoland/deno#12678 is solved, it might be possible to allow a way safely send
ZeroCopyBuf
values, as long as their backing store was created for aSharedArrayBuffer
– but implementingSend
directly onZeroCopyBuf
would still not be sound. We can tackle this when the time comes.See also denoland/rusty_v8#798.
This was discovered when investigating denoland/deno#12341.
The text was updated successfully, but these errors were encountered: