Discussion:
most efficient ( fastest/low latency ) way for an RB app to respond safely to a message/signal sent from a seperate OSX process ?
(too old to reply)
Dan Stenning
2011-07-10 15:36:15 UTC
Permalink
Currently, the great Christian at MBS, has a technique that generates a Carbon Event inside the RB app, in response to a request inside a sepereate pre-emptive thread/process.
Are there any tehniques that can ensure that such a carbon event gets picked up in a prioritised fashion in side the RB framework "executive" ?
For example if i were to move all the RB code needed to respond to such external messages ( in my case a CoreAudio refresh callback executing in another non-RB process ) into a seperate CONSOLE RB app - would this allow such a carbon event to be picked up sooner ( due to lack of a GUI etc ) ?.
Is there a chance that a future version of RB could address a little more of these more "real-time" issues?
This seems pertinent considering we are moving towards a new LLVM compiler that not only promises much better performance, but also in the future the possibility to build dynamic libraries - and hence different kinds of plugins - audio for example.
There is obviously also the "big elephant in the room" of all the requests for RB to handle tru pre-emptive threads in threadsafe fashion. A lot of suggestions have focused on managing multi-core by use of many seperate RB apps. While this is fine for those jobs where one just needs to process data in a parallel fashion safely, it still doesnt give us RB devs a nice way to handle signal interrupts. For handling interrupts optimally one has to handle the interrupt directly - which means using all the "thread safe" techniques discussed elsewhere many times - but always at ones risk and unsupportedby RS. For example if one is careful to only use code that doesnt lock or create/estroy objects, avoids manipulating strings, one still has the limitation that the RB IDE can no longer
trap breakpoints orpause on an RB exception such as nilobject. It would be great to see just a little more functionality for this sort of thing.


Dan
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
Stéphane Mons
2011-07-10 16:19:54 UTC
Permalink
Hi Dan,

I am not sure how "real-time" events are handled. However, there is a "priority" parameter for each event, so I suspect that "real-time" events uses the high priority value. I guess that such events are automatically put appropriately in the events queue. Also, you can install your own event handler for one or more specific type(s). Such handler will be used instead of the default RS event loop handler.

About using a Console app, this is not a good idea because it DOESN'T have a run loop event handler. Moreover, you would have to manage communication between this "helper" application and the GUI one. As the function you describe uses a Callback function, it should be pretty fast and it shouldn't send any Carbon event ?! (or am I wrong ?). I already implemented callbacks from libraries which were from the UNIX world (so they didn't know about Carbon events) and it worked like a charm. I guess the library makes a direct call to the RB code and so it skips the RunEventLoop step.


5 REM My Signature
10 PRINT "Stéphane"
20 GOTO 10


Le 10 juil. 2011 à 17:36, Dan Stenning a écrit :

>
> Currently, the great Christian at MBS, has a technique that generates a Carbon Event inside the RB app, in response to a request inside a sepereate pre-emptive thread/process.
> Are there any tehniques that can ensure that such a carbon event gets picked up in a prioritised fashion in side the RB framework "executive" ?
> For example if i were to move all the RB code needed to respond to such external messages ( in my case a CoreAudio refresh callback executing in another non-RB process ) into a seperate CONSOLE RB app - would this allow such a carbon event to be picked up sooner ( due to lack of a GUI etc ) ?.
> Is there a chance that a future version of RB could address a little more of these more "real-time" issues?
> This seems pertinent considering we are moving towards a new LLVM compiler that not only promises much better performance, but also in the future the possibility to build dynamic libraries - and hence different kinds of plugins - audio for example.
> There is obviously also the "big elephant in the room" of all the requests for RB to handle tru pre-emptive threads in threadsafe fashion. A lot of suggestions have focused on managing multi-core by use of many seperate RB apps. While this is fine for those jobs where one just needs to process data in a parallel fashion safely, it still doesnt give us RB devs a nice way to handle signal interrupts. For handling interrupts optimally one has to handle the interrupt directly - which means using all the "thread safe" techniques discussed elsewhere many times - but always at ones risk and unsupportedby RS. For example if one is careful to only use code that doesnt lock or create/estroy objects, avoids manipulating strings, one still has the limitation that the RB IDE can no longer trap breakpoints orpause on an RB exception such as nilobject. It would be great to see just a little more functionality for this sort of thing.
>
>
> Dan
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
Dan Stenning
2011-07-10 16:53:12 UTC
Permalink
> From: st.mons.lists-***@public.gmane.org
> Moreover, you would have to manage communication between this "helper" application and the GUI one.
that isn't really a problem, ive already got code for that if i need it. it adds some complexity of course by my main concern is real-time issues and performance/latency
> As the function you describe uses a Callback >function, it should be pretty fast and it shouldn't send any Carbon event ?! (or am I wrong ?). > I already implemented callbacks from libraries which were from the UNIX world (so they didn't know about Carbon events) and it worked like a charm.

Nice to hear. Although the RB framework isnt threadsafe so it limits what one can do, plus of course one has to disable all exception handling and far as i can tell single stepping through callbacks generated outsideof the RB thread system is unworkable.
Of course if you issued some call INTO the UNIX system from within the main RB thread then this wouldnt be a problem. its only such if the callback came from outside of the RB app itself.
Dan
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
Stéphane Mons
2011-07-10 18:52:38 UTC
Permalink
Yes, calling a function that can raise an Exception is problematic.

By contrast, I am not sure that RB isn't thread safe. I agree that a call to RB callback does not allow everything to be done (though you can set a Timer to postpone the actions to be taken), but at least cooperative threading allows you to make sure that an object won't be modified while you're using it.

5 REM My Signature
10 PRINT "Stéphane"
20 GOTO 10


Le 10 juil. 2011 à 18:53, Dan Stenning a écrit :

>
>
>> From: st.mons.lists-***@public.gmane.org
>> Moreover, you would have to manage communication between this "helper" application and the GUI one.
> that isn't really a problem, ive already got code for that if i need it. it adds some complexity of course by my main concern is real-time issues and performance/latency
>> As the function you describe uses a Callback >function, it should be pretty fast and it shouldn't send any Carbon event ?! (or am I wrong ?). > I already implemented callbacks from libraries which were from the UNIX world (so they didn't know about Carbon events) and it worked like a charm.
>
> Nice to hear. Although the RB framework isnt threadsafe so it limits what one can do, plus of course one has to disable all exception handling and far as i can tell single stepping through callbacks generated outsideof the RB thread system is unworkable.
> Of course if you issued some call INTO the UNIX system from within the main RB thread then this wouldnt be a problem. its only such if the callback came from outside of the RB app itself.
> Dan
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
Dan Stenning
2011-07-10 19:04:56 UTC
Permalink
RB is threadsafe WITHIN its own co-operative threading system. But generally when people bring up 'thread safe-ness' here the discussion is to do with pre-emptive threads outside of the RB app process.

> Subject: Re: most efficient ( fastest/low latency ) way for an RB app to respond safely to a message/signal sent from a seperate OSX process ?
> From: st.mons.lists-***@public.gmane.org
> Date: Sun, 10 Jul 2011 20:52:38 +0200
> To: realbasic-nug-Gjhu/N1EzaPthnj+***@public.gmane.org
>
> Yes, calling a function that can raise an Exception is problematic.
>
> By contrast, I am not sure that RB isn't thread safe. I agree that a call to RB callback does not allow everything to be done (though you can set a Timer to postpone the actions to be taken), but at least cooperative threading allows you to make sure that an object won't be modified while you're using it.
>
> 5 REM My Signature
> 10 PRINT "Stéphane"
> 20 GOTO 10
>
>
> Le 10 juil. 2011 à 18:53, Dan Stenning a écrit :
>
> >
> >
> >> From: st.mons.lists-***@public.gmane.org
> >> Moreover, you would have to manage communication between this "helper" application and the GUI one.
> > that isn't really a problem, ive already got code for that if i need it. it adds some complexity of course by my main concern is real-time issues and performance/latency
> >> As the function you describe uses a Callback >function, it should be pretty fast and it shouldn't send any Carbon event ?! (or am I wrong ?). > I already implemented callbacks from libraries which were from the UNIX world (so they didn't know about Carbon events) and it worked like a charm.
> >
> > Nice to hear. Although the RB framework isnt threadsafe so it limits what one can do, plus of course one has to disable all exception handling and far as i can tell single stepping through callbacks generated outsideof the RB thread system is unworkable.
> > Of course if you issued some call INTO the UNIX system from within the main RB thread then this wouldnt be a problem. its only such if the callback came from outside of the RB app itself.
> > Dan
> > _______________________________________________
> > Unsubscribe or switch delivery mode:
> > <http://www.realsoftware.com/support/listmanager/>
> >
> > Search the archives:
> > <http://support.realsoftware.com/listarchives/lists.html>
>
>
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
Stéphane Mons
2011-07-10 19:23:07 UTC
Permalink
Well there is no preemptive multitasking at the moment so a library is supposed to be able to call any method inside your project. Why caring about something that doesn't exists yet ?


Le 10 juil. 2011 à 21:04, Dan Stenning a écrit :

>
> RB is threadsafe WITHIN its own co-operative threading system. But generally when people bring up 'thread safe-ness' here the discussion is to do with pre-emptive threads outside of the RB app process.
>
>> Subject: Re: most efficient ( fastest/low latency ) way for an RB app to respond safely to a message/signal sent from a seperate OSX process ?
>> From: st.mons.lists-***@public.gmane.org
>> Date: Sun, 10 Jul 2011 20:52:38 +0200
>> To: realbasic-nug-Gjhu/N1EzaPthnj+***@public.gmane.org
>>
>> Yes, calling a function that can raise an Exception is problematic.
>>
>> By contrast, I am not sure that RB isn't thread safe. I agree that a call to RB callback does not allow everything to be done (though you can set a Timer to postpone the actions to be taken), but at least cooperative threading allows you to make sure that an object won't be modified while you're using it.
>>
>> 5 REM My Signature
>> 10 PRINT "Stéphane"
>> 20 GOTO 10
>>
>>
>> Le 10 juil. 2011 à 18:53, Dan Stenning a écrit :
>>
>>>
>>>
>>>> From: st.mons.lists-***@public.gmane.org
>>>> Moreover, you would have to manage communication between this "helper" application and the GUI one.
>>> that isn't really a problem, ive already got code for that if i need it. it adds some complexity of course by my main concern is real-time issues and performance/latency
>>>> As the function you describe uses a Callback >function, it should be pretty fast and it shouldn't send any Carbon event ?! (or am I wrong ?). > I already implemented callbacks from libraries which were from the UNIX world (so they didn't know about Carbon events) and it worked like a charm.
>>>
>>> Nice to hear. Although the RB framework isnt threadsafe so it limits what one can do, plus of course one has to disable all exception handling and far as i can tell single stepping through callbacks generated outsideof the RB thread system is unworkable.
>>> Of course if you issued some call INTO the UNIX system from within the main RB thread then this wouldnt be a problem. its only such if the callback came from outside of the RB app itself.
>>> Dan
>>> _______________________________________________
>>> Unsubscribe or switch delivery mode:
>>> <http://www.realsoftware.com/support/listmanager/>
>>>
>>> Search the archives:
>>> <http://support.realsoftware.com/listarchives/lists.html>
>>
>>
>>
>> _______________________________________________
>> Unsubscribe or switch delivery mode:
>> <http://www.realsoftware.com/support/listmanager/>
>>
>> Search the archives:
>> <http://support.realsoftware.com/listarchives/lists.html>
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

5 REM My Signature
10 PRINT "Stéphane"
20 GOTO 10




_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
Dan Stenning
2011-07-10 21:03:30 UTC
Permalink
i think we are talking at cross purposes or wires or something here.

Dan
> Subject: Re: most efficient ( fastest/low latency ) way for an RB app to respond safely to a message/signal sent from a seperate OSX process ?
> From: st.mons.lists-***@public.gmane.org
> Date: Sun, 10 Jul 2011 21:23:07 +0200
> To: realbasic-nug-Gjhu/N1EzaPthnj+***@public.gmane.org
>
> Well there is no preemptive multitasking at the moment so a library is supposed to be able to call any method inside your project. Why caring about something that doesn't exists yet ?
>
>
> Le 10 juil. 2011 à 21:04, Dan Stenning a écrit :
>
> >
> > RB is threadsafe WITHIN its own co-operative threading system. But generally when people bring up 'thread safe-ness' here the discussion is to do with pre-emptive threads outside of the RB app process.
> >
> >> Subject: Re: most efficient ( fastest/low latency ) way for an RB app to respond safely to a message/signal sent from a seperate OSX process ?
> >> From: st.mons.lists-***@public.gmane.org
> >> Date: Sun, 10 Jul 2011 20:52:38 +0200
> >> To: realbasic-nug-Gjhu/N1EzaPthnj+***@public.gmane.org
> >>
> >> Yes, calling a function that can raise an Exception is problematic.
> >>
> >> By contrast, I am not sure that RB isn't thread safe. I agree that a call to RB callback does not allow everything to be done (though you can set a Timer to postpone the actions to be taken), but at least cooperative threading allows you to make sure that an object won't be modified while you're using it.
> >>
> >> 5 REM My Signature
> >> 10 PRINT "Stéphane"
> >> 20 GOTO 10
> >>
> >>
> >> Le 10 juil. 2011 à 18:53, Dan Stenning a écrit :
> >>
> >>>
> >>>
> >>>> From: st.mons.lists-***@public.gmane.org
> >>>> Moreover, you would have to manage communication between this "helper" application and the GUI one.
> >>> that isn't really a problem, ive already got code for that if i need it. it adds some complexity of course by my main concern is real-time issues and performance/latency
> >>>> As the function you describe uses a Callback >function, it should be pretty fast and it shouldn't send any Carbon event ?! (or am I wrong ?). > I already implemented callbacks from libraries which were from the UNIX world (so they didn't know about Carbon events) and it worked like a charm.
> >>>
> >>> Nice to hear. Although the RB framework isnt threadsafe so it limits what one can do, plus of course one has to disable all exception handling and far as i can tell single stepping through callbacks generated outsideof the RB thread system is unworkable.
> >>> Of course if you issued some call INTO the UNIX system from within the main RB thread then this wouldnt be a problem. its only such if the callback came from outside of the RB app itself.
> >>> Dan
> >>> _______________________________________________
> >>> Unsubscribe or switch delivery mode:
> >>> <http://www.realsoftware.com/support/listmanager/>
> >>>
> >>> Search the archives:
> >>> <http://support.realsoftware.com/listarchives/lists.html>
> >>
> >>
> >>
> >> _______________________________________________
> >> Unsubscribe or switch delivery mode:
> >> <http://www.realsoftware.com/support/listmanager/>
> >>
> >> Search the archives:
> >> <http://support.realsoftware.com/listarchives/lists.html>
> >
> > _______________________________________________
> > Unsubscribe or switch delivery mode:
> > <http://www.realsoftware.com/support/listmanager/>
> >
> > Search the archives:
> > <http://support.realsoftware.com/listarchives/lists.html>
>
> 5 REM My Signature
> 10 PRINT "Stéphane"
> 20 GOTO 10
>
>
>
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
Continue reading on narkive:
Loading...