Hello,
I've seen that only UnixAioPlugin uses it (at least of internal plugins) and that 'Unix' prefix doesn't really sound good to me :). So, does #signalSemaphoreWithIndex: work on Windows and other platforms? Bye. -- www.lethalman.net - Thoughts about computer technologies |
On Sat, Jun 03, 2006 at 01:06:30PM +0200, Bruno Luca wrote:
> Hello, > I've seen that only UnixAioPlugin uses it (at least of internal plugins) > and that 'Unix' prefix > doesn't really sound good to me :). > So, does #signalSemaphoreWithIndex: work on Windows and other platforms? The #signalSemaphoreWithIndex: method provides a general way to signal a semaphore in the Squeak image from the VM. It works on any platform, including of course Windows. This provides a very nice mechanism for a Process in Squeak "wake up" when some external event happens. If you look at UnixAioPlugin, you'll find that it's really a subclass of AioPlugin, and that the an AioEventHandler (a class in OSProcess that knows how to handle aio events) looks for primitives in the plugin with moduleName 'AioPlugin'. It really does not know that it is using the concrete implementation in UnixAioEventHandler. The intent here is that when someone needs aio event handling for Windows or for Risc OS, they will implement Win32AioPlugin or RiscOSAioPlugin as subclasses of AioPlugin. When building AioPlugin for Windows or RiscOS, VMMaker picks the right subclass to use, and the result is an AioPlugin built with code generated from Win32AioPlugin, RiscOSAioPlugin, or UnixAioPlugin depending on the platform. Anyway, back to your original question: #signalSemaphoreWithIndex: is completely platform-independent and can be used on Windows or any other OS. Dave |
It seem that halo didn't delete properly in 3.9 7033 image.
I have add a little change in PastUpMorph For me it work better deleteAllHalos self haloMorphs do: [:each | (each target isKindOf: SelectionMorph) ifTrue: [each target delete]. each delete]."here" self hands do: [:each | each removeHalo] ___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com |
mathieu a écrit :
> It seem that halo didn't delete properly in 3.9 7033 image. > > I have add a little change in PastUpMorph > For me it work better > > > deleteAllHalos > > self haloMorphs > do: [:each | (each target isKindOf: SelectionMorph) > ifTrue: [each target delete]. > each delete]."here" > self hands > do: [:each | each removeHalo] > Sorry it was me who didn't done the things properly This change make nothings. ___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com |
In reply to this post by David T. Lewis
On Sat, 03 Jun 2006 15:27:32 +0200, David T. Lewis <[hidden email]>
wrote: > On Sat, Jun 03, 2006 at 01:06:30PM +0200, Bruno Luca wrote: >> Hello, >> I've seen that only UnixAioPlugin uses it (at least of internal plugins) >> and that 'Unix' prefix >> doesn't really sound good to me :). >> So, does #signalSemaphoreWithIndex: work on Windows and other platforms? > > The #signalSemaphoreWithIndex: method provides a general way to signal > a semaphore in the Squeak image from the VM. It works on any platform, > including of course Windows. This provides a very nice mechanism for > a Process in Squeak "wake up" when some external event happens. > I didn't try any implementation yet, but i guess i need a threaded loop to check when a Semaphore has been signaled, right? > If you look at UnixAioPlugin, you'll find that it's really a subclass > of AioPlugin, and that the an AioEventHandler (a class in OSProcess > that knows how to handle aio events) looks for primitives in the > plugin with moduleName 'AioPlugin'. It really does not know that it > is using the concrete implementation in UnixAioEventHandler. > > The intent here is that when someone needs aio event handling for > Windows or for Risc OS, they will implement Win32AioPlugin or > RiscOSAioPlugin as subclasses of AioPlugin. When building AioPlugin > for Windows or RiscOS, VMMaker picks the right subclass to use, > and the result is an AioPlugin built with code generated from > Win32AioPlugin, RiscOSAioPlugin, or UnixAioPlugin depending on > the platform. > Ok. > Anyway, back to your original question: #signalSemaphoreWithIndex: > is completely platform-independent and can be used on Windows > or any other OS. > > Dave > Oh ok, i think i've understood how it works basically: it just registers a signal by increasing a count into a C (or even a squeak-side) variable. Thanks for your reply :) -- www.lethalman.net - Thoughts about computer technologies |
On Sat, Jun 03, 2006 at 08:32:26PM +0200, Bruno Luca wrote:
> On Sat, 03 Jun 2006 15:27:32 +0200, David T. Lewis <[hidden email]> > wrote: > > >On Sat, Jun 03, 2006 at 01:06:30PM +0200, Bruno Luca wrote: > >The #signalSemaphoreWithIndex: method provides a general way to signal > >a semaphore in the Squeak image from the VM. It works on any platform, > >including of course Windows. This provides a very nice mechanism for > >a Process in Squeak "wake up" when some external event happens. > > I didn't try any implementation yet, but i guess i need a threaded loop to > check when a Semaphore has been signaled, right? Yes. For an example, look at InputSensor>>installInterruptWatcher. This starts a Smalltalk Process (aka thread) that wakes up when you hit the interrupt key. The VM watches for you to hit the interrupt key, then calls #signalSemaphoreWithIndex: to activate the interrupt watcher process. The interrupt watch process just waits quietly in the background until somebody wakes it up, then it takes over and tries to interrupt whatever Process was running at the time you hit the interrupt key. I assume that you have already loaded VMMaker into your image. If not, load it from SqueakMap and you'll be able to see all the code that makes this work. Also, if you open a ProcessBrowser (from the "Tools" tab) you will see several processes that run in the background and rely on semaphore signals to wake up and do their respective jobs. Dave |
On Sat, 03 Jun 2006 21:34:20 +0200, David T. Lewis <[hidden email]>
wrote: > On Sat, Jun 03, 2006 at 08:32:26PM +0200, Bruno Luca wrote: >> On Sat, 03 Jun 2006 15:27:32 +0200, David T. Lewis <[hidden email]> >> wrote: >> >> >On Sat, Jun 03, 2006 at 01:06:30PM +0200, Bruno Luca wrote: >> >The #signalSemaphoreWithIndex: method provides a general way to signal >> >a semaphore in the Squeak image from the VM. It works on any platform, >> >including of course Windows. This provides a very nice mechanism for >> >a Process in Squeak "wake up" when some external event happens. >> >> I didn't try any implementation yet, but i guess i need a threaded loop >> to >> check when a Semaphore has been signaled, right? > > Yes. For an example, look at InputSensor>>installInterruptWatcher. > This starts a Smalltalk Process (aka thread) that wakes up when you > hit the interrupt key. The VM watches for you to hit the interrupt > key, then calls #signalSemaphoreWithIndex: to activate the interrupt > watcher process. The interrupt watch process just waits quietly in > the background until somebody wakes it up, then it takes over and > tries to interrupt whatever Process was running at the time you > hit the interrupt key. > Yes i've took a look at InputSensor. > I assume that you have already loaded VMMaker into your image. > If not, load it from SqueakMap and you'll be able to see all the > code that makes this work. Also, if you open a ProcessBrowser > (from the "Tools" tab) you will see several processes that run > in the background and rely on semaphore signals to wake up and > do their respective jobs. > > Dave > Thanks :) -- www.lethalman.net - Thoughts about computer technologies |
In reply to this post by Luca Bruno aka Lethalman
lethalman88 said:
> So, does #signalSemaphoreWithIndex: work on Windows and other platforms? Yes it does. It's a feature of the VM (the interpreter), and it's 100% platform independent. In fact, if there is no platform it also works (we are using it in SqueakNOS). David explained why you may want to use it. The counterpart is how to use it: In Squeak at some point you'll want to wait for an external event, for this, you create a Semaphore and register it: <code> sem := Semaphore new. plugin registerSemaphore: (Smalltalk registerExternalObject: sem). </code> With #registerExternalObject: you register the object so it can be accessed from the native world. This is necesary because objects tend to move with Garbage Collection, so if you just used a direct pointer to the object, this pointer would become obsolete when the GC moves the object. #registerExternalObject: puts the object in an array (updated by the GC I guess) and returns an index. your plugin will need to implement something like #registerSemaphore:, for example for SqueakNOS we have: <code> SqueakNOSPlugin>>primitiveRegisterSemaphoreIndex: aSemaphoreIndex forIRQ: irqNumber | IRQSemaphores | self primitive: 'primitiveRegisterSemaphoreIndexForIRQ' parameters: #(SmallInteger SmallInteger). self var: #IRQSemaphores type: 'extern t_IRQSemaphores'. irqNumber < (IRQSemaphores sizeof/(IRQSemaphores at: 0) sizeof) ifTrue: [IRQSemaphores at: irqNumber put: aSemaphoreIndex] ifFalse: [interpreterProxy primitiveFail]. ^ interpreterProxy trueObject </code> where t_IRQSemaphores is nothing more than an array of integers. So we save the index returned by #registerExternalObject: in this array for when we want to use it. When the external even hapens (your native part will know), you need to call #signalSemaphoreWithIndex:, for example: <code> void signalIRQ(int number) { if (0 != IRQSemaphores[number]) signalSemaphoreWithIndex(IRQSemaphores[number]); } </code> and inside Squeak you will have a Process waiting on the Semaphore, for example, the complite code could be: <code> sem := Semaphore new. self primRegisterSemaphore: (Smalltalk registerExternalObject: sem). [[ sem wait. self doSomething] repeat. ] fork. </code> Hope it helps. gera </code> |
In the same mood, check out the example callback plugin that I just
posted over at vm-dev: It uses signalSemaphoreWithIndex() as well. http://discuss.squeakfoundation.org/cgi-bin/ezmlm-browse?list=vm-dev&cmd=showmsg&msgnum=749 Cheers, - Andreas Gerardo Richarte wrote: > lethalman88 said: >> So, does #signalSemaphoreWithIndex: work on Windows and other platforms? > > Yes it does. It's a feature of the VM (the interpreter), and it's 100% platform independent. In fact, if there is no platform it also works (we are using it in SqueakNOS). > > David explained why you may want to use it. The counterpart is how to use it: > > In Squeak at some point you'll want to wait for an external event, for this, you create a Semaphore and register it: > > <code> > sem := Semaphore new. > plugin registerSemaphore: (Smalltalk registerExternalObject: sem). > </code> > > With #registerExternalObject: you register the object so it can be accessed from the native world. This is necesary because objects tend to move with Garbage Collection, so if you just used a direct pointer to the object, this pointer would become obsolete when the GC moves the object. #registerExternalObject: puts the object in an array (updated by the GC I guess) and returns an index. > > your plugin will need to implement something like #registerSemaphore:, for example for SqueakNOS we have: > > <code> > SqueakNOSPlugin>>primitiveRegisterSemaphoreIndex: aSemaphoreIndex forIRQ: irqNumber > | IRQSemaphores | > > self primitive: 'primitiveRegisterSemaphoreIndexForIRQ' > parameters: #(SmallInteger SmallInteger). > > self var: #IRQSemaphores type: 'extern t_IRQSemaphores'. > > irqNumber < (IRQSemaphores sizeof/(IRQSemaphores at: 0) sizeof) > ifTrue: [IRQSemaphores at: irqNumber put: aSemaphoreIndex] > ifFalse: [interpreterProxy primitiveFail]. > > ^ interpreterProxy trueObject > </code> > > where t_IRQSemaphores is nothing more than an array of integers. So we save the index returned by #registerExternalObject: in this array for when we want to use it. > > When the external even hapens (your native part will know), you need to call #signalSemaphoreWithIndex:, for example: > <code> > void signalIRQ(int number) { > if (0 != IRQSemaphores[number]) > signalSemaphoreWithIndex(IRQSemaphores[number]); > } > </code> > > and inside Squeak you will have a Process waiting on the Semaphore, for example, the complite code could be: > > <code> > sem := Semaphore new. > self primRegisterSemaphore: (Smalltalk registerExternalObject: sem). > > [[ > sem wait. > self doSomething] repeat. > ] fork. > </code> > > Hope it helps. > > gera > > </code> > > > > |
Likely I should point out this code is not 100% percent thread safe.
People doing thousands of signal events per second from an async thread should think carefully about the code. This becomes a bit more of a problem given 4GHz machines with dual or quad processors. The original solution to the problem I posted many years ago used a semaphore, but I was told those don't exist on some platforms so the current code does not do thread safe locking of any form. Losing an occasional signal event is of course is a bear to debug... On 9-Jun-06, at 3:37 PM, Andreas Raab wrote: > In the same mood, check out the example callback plugin that I just > posted over at vm-dev: It uses signalSemaphoreWithIndex() as well. > > http://discuss.squeakfoundation.org/cgi-bin/ezmlm-browse?list=vm- > dev&cmd=showmsg&msgnum=749 > > Cheers, > - Andreas > ======================================================================== === John M. McIntosh <[hidden email]> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
John M McIntosh wrote:
> Likely I should point out this code is not 100% percent thread safe. > > People doing thousands of signal events per second from an async thread > should think carefully about the code. > > This becomes a bit more of a problem given 4GHz machines with dual or > quad processors. > The original solution to the problem I posted many years ago used a > semaphore, but I was told those don't exist on some platforms so the > current code does not do thread safe locking of any form. There is a very simple solution to that problem which I implemented quite a while ago: Simply make a platform-specific version of signalSemaphoreWithIndex (in the Win32 VM that version is found in sqWin32Window.c under the name of synchronizedSignalSemaphoreWithIndex) and override the function in the VM proxy. Simple and direct. Cheers, - Andreas |
On 9-Jun-06, at 5:12 PM, Andreas Raab wrote: > John M McIntosh wrote: >> Likely I should point out this code is not 100% percent thread safe. >> People doing thousands of signal events per second from an async >> thread should think carefully about the code. >> This becomes a bit more of a problem given 4GHz machines with dual >> or quad processors. >> The original solution to the problem I posted many years ago used >> a semaphore, but I was told those don't exist on some platforms so >> the current code does not do thread safe locking of any form. > > There is a very simple solution to that problem which I implemented > quite a while ago: Simply make a platform-specific version of > signalSemaphoreWithIndex (in the Win32 VM that version is found in > sqWin32Window.c under the name of > synchronizedSignalSemaphoreWithIndex) and override the function in > the VM proxy. Simple and direct OK, I see your new function ok and I see what it does but after scanning the entire platorms tree I can't spot where you might be overriding the 'normal' signalSemaphoreWithIndex. What did I miss or misunderstand ? If the issue is important for internal use (as intimated in your comment in sqWin32Window.c then perhaps we should make sure that the interp.c code can take advantage of a platform specific function where appropriate. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Sailboat fuel for brains. |
Free forum by Nabble | Edit this page |