interpreterProxy signalSemaphoreWithIndex:

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

interpreterProxy signalSemaphoreWithIndex:

Luca Bruno aka Lethalman
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

Reply | Threaded
Open this post in threaded view
|

Re: interpreterProxy signalSemaphoreWithIndex:

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

deleteAllHalos

Mathieu SUEN
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

Reply | Threaded
Open this post in threaded view
|

Re: deleteAllHalos

Mathieu SUEN
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

Reply | Threaded
Open this post in threaded view
|

Re: interpreterProxy signalSemaphoreWithIndex:

Luca Bruno aka Lethalman
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

Reply | Threaded
Open this post in threaded view
|

Re: interpreterProxy signalSemaphoreWithIndex:

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: interpreterProxy signalSemaphoreWithIndex:

Luca Bruno aka Lethalman
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

Reply | Threaded
Open this post in threaded view
|

Re: interpreterProxy signalSemaphoreWithIndex:

Gerardo Richarte
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>



Reply | Threaded
Open this post in threaded view
|

Re: interpreterProxy signalSemaphoreWithIndex:

Andreas.Raab
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>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: interpreterProxy signalSemaphoreWithIndex:

johnmci
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
========================================================================
===


Reply | Threaded
Open this post in threaded view
|

Re: interpreterProxy signalSemaphoreWithIndex:

Andreas.Raab
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

Reply | Threaded
Open this post in threaded view
|

Re: interpreterProxy signalSemaphoreWithIndex:

timrowledge

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.