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 = = = ======================================================================== |
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/ |
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. > > > > 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. |
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 = = = ======================================================================== |
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 |
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. |
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/ |
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 = = = ======================================================================== |
Free forum by Nabble | Edit this page |