[Vm-dev] VM Maker: VMMaker.oscog-eem.3094.mcz
commits at source.squeak.org
commits at source.squeak.org
Mon Oct 18 23:13:18 UTC 2021
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!
More information about the Vm-dev
mailing list