Running the VM in another thread

> On 02.02.2020, at 06:28, Pierce Ng <[hidden email]> wrote:
>
>
> Hi Eliot and VM hackers,
>
> I wrote the simplest pthread C program that invokes osvm_main() in a
> separate thread.
>
> On Linux Ubuntu 18.04, with minheadless.pharo.cog.spur's
> libPharoVMCore.a and a Pharo 8 image, the program ran to completion
> printing Pharo's command line handler help on stdout.
>
> On MacOS Mojave, the same C program separately linked to
> PharoVMCore.framework and SqueakVMCore.framework crash at the line
> bzero(abstractOpcodes, allocBytes) in compileCogMethod() in
> cogitX64SysV.c
>
> Is this A or B?
>
> A - Not meant to work. The VM must run on the main thread. On Linux the
> program only ran by happenstance.
>
> B - Meant to work. Crashing on MacOS is a bug.
>
>

> On Feb 1, 2020, at 9:28 PM, Pierce Ng <[hidden email]> wrote:
>
> 
> Hi Eliot and VM hackers,
>
> I wrote the simplest pthread C program that invokes osvm_main() in a
> separate thread.
>
> On Linux Ubuntu 18.04, with minheadless.pharo.cog.spur's
> libPharoVMCore.a and a Pharo 8 image, the program ran to completion
> printing Pharo's command line handler help on stdout.
>
> On MacOS Mojave, the same C program separately linked to
> PharoVMCore.framework and SqueakVMCore.framework crash at the line
> bzero(abstractOpcodes, allocBytes) in compileCogMethod() in
> cogitX64SysV.c
>
> Is this A or B?
>
> A - Not meant to work. The VM must run on the main thread. On Linux the
> program only ran by happenstance.
>
> B - Meant to work. Crashing on MacOS is a bug.

>
>  On Sun, Feb 02, 2020 at 11:25:07PM -0800, Eliot Miranda wrote:
> > > Is this A or B?
> > >
> > > A - Not meant to work. The VM must run on the main thread. On Linux the
> > > program only ran by happenstance.
> > >
> > > B - Meant to work. Crashing on MacOS is a bug.
> >
> > C. There are restrictions on interacting with the GUI on MacOS. I’m
> > not an expert here. John McIntosh can state what the restrictions are.
>
> I should've been clearer. The program is command line only, there is no
> GUI. It is really just one step beyond hello world. I've attached it in
> this mail.
>
> On MacOS I created an Xcode project to link with the Pharo/Squeak VM
> framework because it is quicker that way.
>
> > I’m curious why you want to run the vm in another thread.  I’m curious
> > what your goals are here.  There are a number of potential viable
> > paths to take wrt the vm and threading.
>
> In the headless branch of Pharo's fork, the Smalltalk image access
> routines have been made pluggable. Pablo Tesone created an example that
> reads the image from a Windows resource that is embedded into a compiled
> host program.
>
> I implemented the image-in-Windows-resource access routines in Free
> Pascal as that functionality comes for free with Free Pascal and is
> cross-platform.
>
> With a couple of FFI, I then have a single-source Pascal program that
> builds on Linux, MacOS and Windows, that runs a Pharo image embedded in
> a Windows resource embedded in said Pascal program.
>
> Then I rewrote the Pascal program to use pthreads. It works on Linux but
> crashes on MacOS, so I wrote the C pthread program mentioned in this
> mail.
>
> My goal is to determine feasibility of building GUIs with Free Pascal /
> Lazarus, while running Pharo on another thread handling app logic, with
> its image embedded and read-only, and have the two communicate via IPC.
>
> Actually, on desktops, running the VM on another thread is not that
> important, because I can and should follow the Firefox/Chrome
> multi-process architecture, with GUI and embedded Pharo as separate
> compiled programs running in separate OS processes.
>
> On iOS/Android, being able to run the VM in another thread might still
> be desirable.
>
> Some links:
>
> - https://github.com/tesonep/pharo-vm-embedded-example (Pablo's example)
> - https://github.com/PierceNg/pharo-vm-embedded-pascal (My Pascal experimentation)
> - https://www.lazarus-ide.org/ (Lazarus)
> - https://www.freepascal.org (Free Pascal)
>
> Pierce