[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