>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.