On May 8, 2008, at 12:30 AM, John M McIntosh wrote:

> Ok, a bit more progress. There is still quite a few things to puzzle  
> out.
>
> I don't want to pound the VM with a ticker update every millisecond.
> I don't have a nice way to schedule a wakeup event sometime in the  
> future by using some generic pthread service.

You use the libSystem.dylib API? (where /usr/lib/libpthread.dylib  
points to)?
I'll see it when I get your code.

> I therefore re-implemented the logic that clock checks every message  
> send and backward jump to
> check the current time and consider the next wakeup time. Likely  
> we'll have to tune this, or perhaps 0.5% of
> run time devoted to looking at the clock is just good enough  
> programming.

Or use it now, and return to it in a years time when our insight in  
this problem has improved.
Unless it involves extensive coding.

Amit Singh might have a good solution handy. I am looking through http://www.kernelthread.com 
  right now.

> Given all that I'm still dealing with having the second instance of  
> the interpreter unlock the global vm logic so plugins can load in a  
> clean manner.
> I did stick in a change where it does halt the 2nd instance when  
> there is no squeak process runnable and no pending Delay but that  
> isn't a correct solution.
>
> However I now am at the point where I can do
>
> HydraVM loadAndRunNewImage: 'test.image'
>
> HydraVM doIt: 'Transcript show: 10000 factorial' at: 2
>
Wow!


> Which then prints a really big number, later.
> I can of course interact with the main interpreter instance, and  
> also do the 10000 factorial,
> which then makes my machine run at 200% cpu and whirl the fans to  
> high.

Great. And yes, it will always involve having the fans go full blast  
with 4/8 cores.

> Going forward I need some folks who can compile the VM and do some  
> testing.

That is what I can do well. I always find bugs.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080508/6cb7ac00/attachment.htm