2008/5/13 John M McIntosh <johnmci at smalltalkconsulting.com>:
> Ok, I've check in my changes for the Mac Carbon Hydra update, (oh
> likely missing something).
> This also includes platform specfic pthread code and the
> re-worked-hacked  event queue code.
> http://squeakvm.org/svn/squeak/branches/HydraVM
> I suspect the pthread code could be integrated with any effort on the
> unix port.
>
> To compile use the SqueakVMHydra.xcodeproj project.
>
> I also have a VMMaker-JMM.81.mcz I should put somewhere, but not sure where?
>

I think SqueakSource is a good place for it.
Need to register project.

>
> I had a few notes such as the
>
> (a) ioSqueakImageSize() should return a squeakFileOffsetType  (I've
> not fixed that yet)
> (b) More importantly the Hydra interpreter is NOT 32bit clean since it
> is missing the changes David T Lewis did for ensuring addresses > 2GB
> won't crash the VM.
> (c) I did not gunify the interp.c loop yet, someone might see about
> that after someone ensures the interpreter is 32bit clean.
> (d) You can only build the VM as a windows VM, the Hydra VMMaker
> changes break building macintosh, or unix VM.
> (e) because of (d) the carbn VM does not have the
> InternetConfigPlugin, MIDIPlugin, MacMenubarPlugin, SerialPlugin, and
> SoundGenerationPlugin
> (f) the GCC 3.3 compiler won't let us build a powerpc VM because
> "sqInt pluginStateId;" is defined for *each*  plugin generated and GCC
> 3.3 won't link those multiple defined symbols
>
>
> Other fun things.
>
> Because the window VM relies on special timer magic to pop an event
> when the next Delay wakeup is needed, or every 20ms.
>
> We of course need to do something similar for non-windows machines.
> I ensure that browserPluginReturnIfNeeded() is called on each send,
> and on each jump backwards, similar to the original
> checkForInterrupts. Missing are calls on activate new method and I
> think perform.
> On the macintosh version browserPluginReturnIfNeeded  puts a dummy
> event on the queue every 16 milliseconds for secondary VMs, or watches
> the clock to see if the Timer Semaphore should be queued
>  if the current time is equal to or in the past as compared to the
> wakeup time.   Hopefully this code handles millisecond clock rollover
> but I did NOT test this.
> Putting the event on the queue then causes the interp.c  interpreter
> loop to exit and we then process the queue to ignore the dummy event,
> or fire the Timer Semaphore.
> Note the dummy event is needed in order for secondary VMs to unlock
> their mutex so that the plugin loading logic will work.
>
> Going forward
>
> I would guess some platform dependent pthread code could handle the
> next wakeup event, but at what cost?
> I'll let people fiddle with things and await feedback.
>
>



-- 
Best regards,
Igor Stasenko AKA sig.