Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.3094.mcz
==================== Summary ====================
Name: VMMaker.oscog-eem.3094 Author: eem Time: 18 October 2021, 4:13:04.230908 pm UUID: 88e65fe6-60c5-46f2-99b1-fa014fde6d7a Ancestors: VMMaker.oscog-eem.3093
CoInterpreterMT & StackInterpreter must agree on the defs of DisownVMForFFICall & DisownVMForThreading.
=============== Diff against VMMaker.oscog-eem.3093 ===============
Item was changed: ----- Method: CoInterpreterMT class>>initializeSchedulerIndices (in category 'initialization') ----- initializeSchedulerIndices super initializeSchedulerIndices. "Class Process" "The thread id of a process is either nil or a SmallInteger that defines how a process binds to threads. If nil, the process may run on any thread. The least significant bit of threadId is a flag. The most significant bits are a threadId. If the threadId is nil the process can run on any thread. If the flag (least significant bit) is set then If the threadId is positive the process can only be run on the thread with that thread Id. If the threadId is negative the process must not be run on the thread with that thread Id. If the flag (least significant bit) is not set then the thread id will not be negative and if non-zero is the id of the thread the process is currenty running on The flag is probably a mistake..."
"In part, what's really going on here is an attempt to deal with threading on Mac. Events can only be delivered on the GUi thread. To avoid blocking and/or crashing the VM by making a blocking (e.g. FFI) call on the GUI thread we want a nice way of preventing a process from running on the GUI thread. We can then use a process whose threadId precludes running on the GUI thread to make blocking calls. The alternative, of arranging that events are delivered to a thread the VM does not run on, is problematic; it cannot support event callbacks."
"So if we simplify, and threadId is only instructive to the VM, (i.e. can say ''run on a given thread'', or ''don't run on a given thread'', and ''don't care; run on any thread'') and does not necessarily hold the threadId of the thread the process is currenty bound to, how do we locate the threadId for a process temporarily affined to a thread for the duration of an FFI call? Note that a process *must* be bound to a thread for the duration of a threaded call (or foreign callback) so that return occurs on the correct thread. We can use the least significant bit to mean ''temporarily affined'', but we need to support ''don't run on this thread''. We could use bit fields (yuck); we could allocate a two field object and assign it to threadId when setting a process to not run on a given thread.
This isn't so bad; use negative values to mean ''don't run on this thread'', and positive values to mean ''run on this thread''. Split the smallest SmallInteger (32-bit, 1 bit sign, 2-bit tags, leaving 29//2) into two 14 bit fields. The least significant 14 bits are the thread id the receiver is temporarily affined to. The most significant 14 bits are the thread id of the thread the proess is either bound to or excluded from. If zero, the process is agnostic. See CogThreadManager>>#maxNumThreads" ThreadIdIndex := 4. ThreadIdShift := 14. "could be 30 in 64-bits"
"disown result/own argument flags" OwnVMForeignThreadFlag := 1. VMAlreadyOwnedHenceDoNotDisown := 2. ProcessUnaffinedOnDisown := 4. "& defined in StackInterpreter are..." + DisownVMForFFICall := 16. + DisownVMForThreading := 32. + DisownFlagsShift := DisownVMForThreading highBit! - DisownVMForFFICall := 8. - DisownVMForThreading := 16. - DisownFlagsShift := 5!
vm-dev@lists.squeakfoundation.org