At the moment, calling an external primitive occurs in the same native thread as the rest of VM, which means everything grinds to a halt until the primitive is complete.
It is not required that a primitive does it's work in the same OS thread that is executing Smalltalk. I believe there are primitives used by Squeak already that use a separate OS thread to accomplish their work. I think the file i/o primitives on the Macintosh work this way. And the network I/O primitives used by NetCorrespondent are also asynchronous.
The question is this - is it possible to add another parameter to the <primitive> call which tells the VM to attempt to run the (thread-safe) primitive in another native thread, and suspend the current Smalltalk Process, then resume it when the primitive completes.
Yes, but this is not the way one would normally accomplish this. Instead async 'read' primitives would be given a Semaphore to signal when they have the data requested. Then the 'read' primitive could fork a separate OS thread to accomplish the work and the primitive would return immediately. When the forked thread finishes it would signal the Semaphore. Then Smalltalk would call a second primitive to get the data from the VM.
This allows other Processes in Smalltalk to run while an asynchronous primitive runs.