[squeak-dev] building Hydra

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] building Hydra

johnmci
Ok, I was trying to make a bit more progress in building a hydra VM  
for non-windows machines.

I was going to ask about the intent of the changes in

primitiveSignalAtMilliseconds
and the removal of nextWakeupTick

but then figured it out, however I'll just continue writing in case  
someone else runs across this question.

In the original code

nextWakeupTick was set to the millisecond clock value when the next  
Delay wakeup needed service.

The process scheduler when it found no more work to be done would call  
the idle process which calls

ioRelinquishProcessorForMicroseconds

That routine at least on the macintosh would then ask for the  
nextWakeupTick and if it was in the
future it would sleep until that time, or some other UI or async  
interrupt (file/socket) occurred.
Then wakeup and return control to the process scheduler which likely  
would find a Delay to service
or some sort of pending interrupt.

But in the Hydra VM I see nextWakeupTick is gone and replaced with

   event = WIN32_STATE(wakeUpEvent);

which I'm assuming is trying to do the same type of activity but in a  
more windows centric manner?
so it appears then that ioScheduleTimerSemaphoreSignalAt   passes in  
the next wakeup time,
then later in ioRelinquishProcessorForMicroseconds you take that data  
and do the proper wait.

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] building Hydra

Tapple Gao
On Tue, Apr 29, 2008 at 10:56:56AM -0700, John M McIntosh wrote:

> Ok, I was trying to make a bit more progress in building a hydra VM for
> non-windows machines.
>
> I was going to ask about the intent of the changes in
>
> primitiveSignalAtMilliseconds
> and the removal of nextWakeupTick
>
> but then figured it out, however I'll just continue writing in case someone
> else runs across this question.
>
> In the original code
>
> nextWakeupTick was set to the millisecond clock value when the next Delay
> wakeup needed service.
>
> The process scheduler when it found no more work to be done would call the
> idle process which calls
>
> ioRelinquishProcessorForMicroseconds
>
> That routine at least on the macintosh would then ask for the
> nextWakeupTick and if it was in the
> future it would sleep until that time, or some other UI or async interrupt
> (file/socket) occurred.
> Then wakeup and return control to the process scheduler which likely would
> find a Delay to service
> or some sort of pending interrupt.
>
> But in the Hydra VM I see nextWakeupTick is gone and replaced with
>
>   event = WIN32_STATE(wakeUpEvent);

I asked Igor about it, and he said the intent of the new
ioWakeUp call is to do whatever it takes to abort the sleep the
VM may be in currently. This means doing dummy io with no effect
other than to abort ioRelinquishProcessorForMicroseconds.

> which I'm assuming is trying to do the same type of activity but in a more
> windows centric manner?
> so it appears then that ioScheduleTimerSemaphoreSignalAt   passes in the
> next wakeup time,
> then later in ioRelinquishProcessorForMicroseconds you take that data and
> do the proper wait.

The intent was to get polling out of the VM and make it more
event driven. Maybe what that means here is that scheduling a
timer interrupt is now not part of
ioRelinquishProcessorForMicroseconds anymore. I'm not familiar
with the old way the VM works; I've only seen the hydra way

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] building Hydra

Igor Stasenko
2008/4/29 Matthew Fulmer <[hidden email]>:

> On Tue, Apr 29, 2008 at 10:56:56AM -0700, John M McIntosh wrote:
>  > Ok, I was trying to make a bit more progress in building a hydra VM for
>  > non-windows machines.
>  >
>  > I was going to ask about the intent of the changes in
>  >
>  > primitiveSignalAtMilliseconds
>  > and the removal of nextWakeupTick
>  >
>  > but then figured it out, however I'll just continue writing in case someone
>  > else runs across this question.
>  >
>  > In the original code
>  >
>  > nextWakeupTick was set to the millisecond clock value when the next Delay
>  > wakeup needed service.
>  >
>  > The process scheduler when it found no more work to be done would call the
>  > idle process which calls
>  >
>  > ioRelinquishProcessorForMicroseconds
>  >
>  > That routine at least on the macintosh would then ask for the
>  > nextWakeupTick and if it was in the
>  > future it would sleep until that time, or some other UI or async interrupt
>  > (file/socket) occurred.
>  > Then wakeup and return control to the process scheduler which likely would
>  > find a Delay to service
>  > or some sort of pending interrupt.
>  >
>  > But in the Hydra VM I see nextWakeupTick is gone and replaced with
>  >
>  >   event = WIN32_STATE(wakeUpEvent);
>
>  I asked Igor about it, and he said the intent of the new
>  ioWakeUp call is to do whatever it takes to abort the sleep the
>  VM may be in currently. This means doing dummy io with no effect
>  other than to abort ioRelinquishProcessorForMicroseconds.
>
Right

>
>  > which I'm assuming is trying to do the same type of activity but in a more
>  > windows centric manner?
>  > so it appears then that ioScheduleTimerSemaphoreSignalAt   passes in the
>  > next wakeup time,
>  > then later in ioRelinquishProcessorForMicroseconds you take that data and
>  > do the proper wait.
>
>  The intent was to get polling out of the VM and make it more
>  event driven. Maybe what that means here is that scheduling a
>  timer interrupt is now not part of
>  ioRelinquishProcessorForMicroseconds anymore. I'm not familiar
>  with the old way the VM works; I've only seen the hydra way
>

Thank you Matthew for clearly expressing my intents. My English is not
very well, but i'm working on it :)

>  --
>  Matthew Fulmer -- http://mtfulmer.wordpress.com/
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] building Hydra

johnmci
In reply to this post by Tapple Gao

On Apr 29, 2008, at 12:33 PM, Matthew Fulmer wrote:
>
> The intent was to get polling out of the VM and make it more
> event driven. Maybe what that means here is that scheduling a
> timer interrupt is now not part of
> ioRelinquishProcessorForMicroseconds anymore. I'm not familiar
> with the old way the VM works; I've only seen the hydra way
>
> --  
> Matthew Fulmer -- http://mtfulmer.wordpress.com/

Ah, ok, well I sent Igor a copy of my current work on the hydra  
semaphore mutex calls. If you
have a InterlockedCompareExchange, and a ioWakeUp() routine that you  
can share that would be helpful.


--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] building Hydra

Tom Rushworth-3
For InterlockedCompareExchange:

    Mac - look in /Developer/SDKs/*/usr/include/libkern/OSAtomic.h for
       OSAtomicCompareAndSwap32(___)
    and friends.

    Linux - last I looked (fall 2007) you pretty much had to roll  
your own,
    since it isn't a standard library function.  I googled and
    found someone's inline asm code for a compare and swap.  I
    can't find where I put it at the moment, you can probably
    find it just as easily googling for it yourself.

No idea about ioWakeUp().

On 08-Apr-29, at 14:20, John M McIntosh wrote:

>
> On Apr 29, 2008, at 12:33 PM, Matthew Fulmer wrote:
>>
>> The intent was to get polling out of the VM and make it more
>> event driven. Maybe what that means here is that scheduling a
>> timer interrupt is now not part of
>> ioRelinquishProcessorForMicroseconds anymore. I'm not familiar
>> with the old way the VM works; I've only seen the hydra way
>>
>> -- Matthew Fulmer -- http://mtfulmer.wordpress.com/
>
> Ah, ok, well I sent Igor a copy of my current work on the hydra  
> semaphore mutex calls. If you
> have a InterlockedCompareExchange, and a ioWakeUp() routine that  
> you can share that would be helpful.
>
>
> --
> ======================================================================
> =====
> John M. McIntosh <[hidden email]>
> Corporate Smalltalk Consulting Ltd.  http://
> www.smalltalkconsulting.com
> ======================================================================
> =====
>
>
>

--
Tom Rushworth




Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] building Hydra

Igor Stasenko
In reply to this post by johnmci
2008/4/30 John M McIntosh <[hidden email]>:

>
>  On Apr 29, 2008, at 12:33 PM, Matthew Fulmer wrote:
>
> >
> > The intent was to get polling out of the VM and make it more
> > event driven. Maybe what that means here is that scheduling a
> > timer interrupt is now not part of
> > ioRelinquishProcessorForMicroseconds anymore. I'm not familiar
> > with the old way the VM works; I've only seen the hydra way
> >
> > -- Matthew Fulmer -- http://mtfulmer.wordpress.com/
> >
>
>  Ah, ok, well I sent Igor a copy of my current work on the hydra semaphore
> mutex calls. If you
>  have a InterlockedCompareExchange, and a ioWakeUp() routine that you can
> share that would be helpful.
>
>

To support non-atomic event queues (wrapped by mutex), some things
need to be changed:

typedef struct vmEventQueue {
        struct vmEvent * volatile tail;
        struct vmEvent head;
        VM_EVENT_QUEUE_PLATFORM_SPECIFIC
} vmEventQueue;

then you can #define  VM_EVENT_QUEUE_OS_SPECIFIC  pthread_mutex  queue_lock;
and also, there are need in additional function to finalize queue:
ioDestroyEventQueue(..)

Currently, i placed vmEventQueue in sqMemoryAccess.h header file, not
sure if platform specific stuff loaded before that header.


About ioWakeUp and event handling:
- if its possible to handle user input from OS in separate thread,
then things can be greatly simplified.

in ioRelinquishProcessorForMicroseconds you simply put wait for
wakeupEvent (pthread's conditional variable), and in OS thread, which
handling events - just translate event, put it into VM event queue and
then call ioWakeUp which should signal wakeupEvent.

In another i/o frameworks , like socket plugin or async file plugin,
things can be done very similar: in own thread, whenever it sees i/o
activity, it just posts VM event and calls ioWakeUp() at the end.
This will eliminate the need to keep track of numerous file handles,
as i saw in current implementation of
ioRelinquishProcessorForMicroseconds() for unix VM port.

Also, if events are not of critical importance, you can just put them
in queue, VM will handle them sooner or later.
In contrast to old implementation, where you needed to call
forceInterruptCheck(), in Hydra the Interpreter loop interrupts
immediately only and only if there are event in its queue, so, in most
cases you just need to post event and you are done.

>
>
>  --
>  ===========================================================================
>  John M. McIntosh <[hidden email]>
>  Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>  ===========================================================================
>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] building Hydra

Tapple Gao
In reply to this post by johnmci
On Tue, Apr 29, 2008 at 02:20:33PM -0700, John M McIntosh wrote:

>
> On Apr 29, 2008, at 12:33 PM, Matthew Fulmer wrote:
>>
>> The intent was to get polling out of the VM and make it more
>> event driven. Maybe what that means here is that scheduling a
>> timer interrupt is now not part of
>> ioRelinquishProcessorForMicroseconds anymore. I'm not familiar
>> with the old way the VM works; I've only seen the hydra way
>>
>> -- Matthew Fulmer -- http://mtfulmer.wordpress.com/
>
> Ah, ok, well I sent Igor a copy of my current work on the hydra semaphore
> mutex calls. If you
> have a InterlockedCompareExchange, and a ioWakeUp() routine that you can
> share that would be helpful.

I'm working on ioWakeUp() right now. Currently, I'm thinking
posting a dummy event to the X input stream may be best for the
X11 vm, specifically the NoExpose event

The windows VM seems to take a similar approach, from what I can
guess about what SetEvent() is

Are you working on a mac port of hydra? I'm working on a linux
port, but I havn't yet posted my code anywhere. I implemented
the mutex stuff via pthreads; hopefully correctly.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] building Hydra

johnmci
In reply to this post by Tom Rushworth-3
Ah, thank you, if you read the fine print, it's actually  
OSAtomicCompareAndSwap32Barrier is what is called for.

On Apr 29, 2008, at 3:09 PM, Tom Rushworth wrote:

> For InterlockedCompareExchange:
>
>   Mac - look in /Developer/SDKs/*/usr/include/libkern/OSAtomic.h for
>      OSAtomicCompareAndSwap32(___)
>   and friends.
>
>   Linux - last I looked (fall 2007) you pretty much had to roll your  
> own,
>   since it isn't a standard library function.  I googled and
>   found someone's inline asm code for a compare and swap.  I
>   can't find where I put it at the moment, you can probably
>   find it just as easily googling for it yourself.
>
> No idea about ioWakeUp().

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================