Re: [Oorexx-devel] Problem in a multihreaded environment with the change from the guarded method default of expose-less methods to unguarded ...
Hi Guys,
This is awkward, I think this change was made in response to my expressing
surprise that the guard made a difference to methods which have no
variables exposed - something that I still don't understand, but have no
need to understand. However, if you think it should go, then I'm content
for it to go.
BTW, and just for correctness sake, I think the default guard state was
changed before, sometime in version 3.x I think. I remember that I had to
change all my oodialog message handling methods to be explicitly unguarded.
Jon
On Sat, 7 Aug 2021, 18:36 Jean Louis Faucher, wrote:
> +1
>
> If you run the example 12.4 of rexxref, you will see that it breaks the
> rule written just above.
>
>
> Regards
>
> On 7 Aug 2021, at 18:28, Rony G. Flatscher
> wrote:
>
> Sleeping and thinking more over it I would suggest to remove this feature
> altogether! The major reasing being that the Rexx philosophy (and ooRexx by
> extension) should make coding as easy as possible for programmers.
>
> The default for methods (and related) has always been "guarded" such that
> one would not have to write "guarded" to the method directive. With that
> default only in very rare cases (in multithreaded scenarios) would one have
> to write "unguarded" to a method directive. And if doing so one must have
> an understanding of multithreading and the ramifications if someone would
> want a method to run unguarded.
>
> Compare this to the current situation with this new feature on: in order
> to fix BSF.CLS all of a sudden I had to add the keyword "guarded" to every
> method to gain the default behaviour for ooRexx < 5.0 and thereby
> re-enabling correct execution of GUI nutshell examples.
>
> Ad feature: originally it was thought to be helpful to programmers by
> saving the programmers to write "unguarded" to a method directive for a
> method that is known to be safe in unguarded mode thinking that methods
> that have no direct access to the attribute pool (i.e. the method routine
> would not start with "expose" or "use local") qualify for unguarded
> execution not thinking about scenarios where this is not enough.
>
> To make it easy for the programmer (i.e. not having to know additional,
> sometimes quite subtle, concepts that play a role in this context) I would
> be in a strong favor to leave the default "guarded" in place. Then either
> remove this new feature altogether or make it an explicit option a
> programmer has to state ("::OPTIONS" with a new pair "guarded|unguarded").
>
> What opinions have others? Do you concur?
>
> ---rony
>
>
> On 06.08.2021 15:09, Rony G. Flatscher wrote:
>
> Background: In order for ooRexx programmers getting acquainted with
> BSF4ooRexx/Java quickly there are numerous nutshell examples in
> "bsf4rexx/samples". Most of these nutshell examples stem from observations
> of students over time who should get help by demonstrating them how to
> achieve something of interest with these (mostly brief) nutshell examples.
>
> One interesting problem has been the interaction from ooRexx with GUI
> objects which must be carried out on the GUI threads in Java (the "awt
> thread" or the "JavaFX Application thread"). Although they got the
> necessary information about the architecture and what to do in ordert to
> become able to send messages on GUI threads, they kept running into
> problems, losing a lot of time (even months because they could not get it
> working in more complex programs).
>
> To make a long story short, I came up with a message based solution, that
> was very easy to understand and to employ for them. None of the students
> ran into the GUI thread problems since then.
>
> The solution is an ooRexx class for awt (the Java "abstract windows
> toolkit") named .AwtGuiThread and for JavaFX (a powerful GUI system)
> .FxGuiThread, both subclassing a common superclass .AbstractGuiThread.
> These classes allow one to send the ooRexx message
> runLater[Latest](GUIreceiver, messageName, arguments) which get queued and
> dispatched on the GUI thread later.
>
> The nutshell examples
> "bsf4rexx/samples/3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj" and
> "bsf4rexx/samples/JavaFX/javafx_update_GUI-from-non-GUI-thread.rxj"
> demonstrate how to employ this infrastructure. They have been working for
> years without a problem.
>
> While working on BSF4ooRexx I stumbled over an error (not having run those
> two examples for quite some time) which seems to indicate that ooRexx now
> creates an error when being used from different threads:
>
> F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\samples>3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj
> screenSize: [java.awt.Dimension[width=1920,height=1080]]
> winSize : [java.awt.Dimension[width=800,height=200]]
> xPos=[560] yPos=[440]
> a REXXEVENTHANDLER::actionPerformed - starting Rexx thread
> The SOME_REXX_CLASS class::updateGuiFromRexxThread - just arrived, GUI
> thread: 23808
> The SOME_REXX_CLASS class::updateGuiFromRexxThread - now running on
Re: [Oorexx-devel] Problem in a multihreaded environment with the change from the guarded method default of expose-less methods to unguarded ...
+1
If you run the example 12.4 of rexxref, you will see that it breaks the rule
written just above.
Regards
> On 7 Aug 2021, at 18:28, Rony G. Flatscher wrote:
>
> Sleeping and thinking more over it I would suggest to remove this feature
> altogether! The major reasing being that the Rexx philosophy (and ooRexx by
> extension) should make coding as easy as possible for programmers.
>
> The default for methods (and related) has always been "guarded" such that one
> would not have to write "guarded" to the method directive. With that default
> only in very rare cases (in multithreaded scenarios) would one have to write
> "unguarded" to a method directive. And if doing so one must have an
> understanding of multithreading and the ramifications if someone would want a
> method to run unguarded.
>
> Compare this to the current situation with this new feature on: in order to
> fix BSF.CLS all of a sudden I had to add the keyword "guarded" to every
> method to gain the default behaviour for ooRexx < 5.0 and thereby re-enabling
> correct execution of GUI nutshell examples.
> Ad feature: originally it was thought to be helpful to programmers by saving
> the programmers to write "unguarded" to a method directive for a method that
> is known to be safe in unguarded mode thinking that methods that have no
> direct access to the attribute pool (i.e. the method routine would not start
> with "expose" or "use local") qualify for unguarded execution not thinking
> about scenarios where this is not enough.
> To make it easy for the programmer (i.e. not having to know additional,
> sometimes quite subtle, concepts that play a role in this context) I would be
> in a strong favor to leave the default "guarded" in place. Then either remove
> this new feature altogether or make it an explicit option a programmer has to
> state ("::OPTIONS" with a new pair "guarded|unguarded").
>
> What opinions have others? Do you concur?
> ---rony
>
> On 06.08.2021 15:09, Rony G. Flatscher wrote:
>> Background: In order for ooRexx programmers getting acquainted with
>> BSF4ooRexx/Java quickly there are numerous nutshell examples in
>> "bsf4rexx/samples". Most of these nutshell examples stem from observations
>> of students over time who should get help by demonstrating them how to
>> achieve something of interest with these (mostly brief) nutshell examples.
>>
>> One interesting problem has been the interaction from ooRexx with GUI
>> objects which must be carried out on the GUI threads in Java (the "awt
>> thread" or the "JavaFX Application thread"). Although they got the necessary
>> information about the architecture and what to do in ordert to become able
>> to send messages on GUI threads, they kept running into problems, losing a
>> lot of time (even months because they could not get it working in more
>> complex programs).
>>
>> To make a long story short, I came up with a message based solution, that
>> was very easy to understand and to employ for them. None of the students ran
>> into the GUI thread problems since then.
>>
>> The solution is an ooRexx class for awt (the Java "abstract windows
>> toolkit") named .AwtGuiThread and for JavaFX (a powerful GUI system)
>> .FxGuiThread, both subclassing a common superclass .AbstractGuiThread. These
>> classes allow one to send the ooRexx message runLater[Latest](GUIreceiver,
>> messageName, arguments) which get queued and dispatched on the GUI thread
>> later.
>> The nutshell examples
>> "bsf4rexx/samples/3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj" and
>> "bsf4rexx/samples/JavaFX/javafx_update_GUI-from-non-GUI-thread.rxj"
>> demonstrate how to employ this infrastructure. They have been working for
>> years without a problem.
>>
>> While working on BSF4ooRexx I stumbled over an error (not having run those
>> two examples for quite some time) which seems to indicate that ooRexx now
>> creates an error when being used from different threads:
>>
>> F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\samples>3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj
>> screenSize: [java.awt.Dimension[width=1920,height=1080]]
>> winSize : [java.awt.Dimension[width=800,height=200]]
>> xPos=[560] yPos=[440]
>> a REXXEVENTHANDLER::actionPerformed - starting Rexx thread
>> The SOME_REXX_CLASS class::updateGuiFromRexxThread - just arrived, GUI
>> thread: 23808
>> The SOME_REXX_CLASS class::updateGuiFromRexxThread - now running on thread:
>> 7428
>>*-* Compiled method "DELETE" with scope "Queue".
>> 5727 *-* msgQueue~delete(idx) -- delete the guiMsg object
>> 5637 *-* forward message "REMOVEMESSAGE" continue -- remove all GUI
>> messages of the same name targeted to the same object
>>207 *-* .AwtGuiThread~runLaterLatest(label, "setText", "i", str)
>> Error 93 running
>> F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\samples\3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj
>> line 207: Incorrect
>> call to method.
>> Error
Re: [Oorexx-devel] Problem in a multihreaded environment with the change from the guarded method default of expose-less methods to unguarded ...
Sleeping and thinking more over it I would suggest to remove this feature
altogether! The major
reasing being that the Rexx philosophy (and ooRexx by extension) should make
coding as easy as
possible for programmers.
The default for methods (and related) has always been "guarded" such that one
would not have to
write "guarded" to the method directive. With that default only in very rare
cases (in multithreaded
scenarios) would one have to write "unguarded" to a method directive. And if
doing so one must have
an understanding of multithreading and the ramifications if someone would want
a method to run
unguarded.
Compare this to the current situation with this new feature on: in order to fix
BSF.CLSÂ all of a
sudden I had to add the keyword "guarded" to every method to gain the default
behaviour for ooRexx <
5.0 and thereby re-enabling correct execution of GUI nutshell examples.
Ad feature: originally it was thought to be helpful to programmers by saving
the programmers to
write "unguarded" to a method directive for a method that is known to be safe
in unguarded mode
thinking that methods that have no direct access to the attribute pool (i.e.
the method routine
would not start with "expose" or "use local") qualify for unguarded execution
not thinking about
scenarios where this is not enough.
To make it easy for the programmer (i.e. not having to know additional,
sometimes quite subtle,
concepts that play a role in this context) I would be in a strong favor to
leave the default
"guarded" in place. Then either remove this new feature altogether or make it
an explicit option a
programmer has to state ("::OPTIONS" with a new pair "guarded|unguarded").
What opinions have others? Do you concur?
---rony
On 06.08.2021 15:09, Rony G. Flatscher wrote:
>
> Background: In order for ooRexx programmers getting acquainted with
> BSF4ooRexx/Java quickly there
> are numerous nutshell examples in "bsf4rexx/samples". Most of these nutshell
> examples stem from
> observations of students over time who should get help by demonstrating them
> how to achieve
> something of interest with these (mostly brief) nutshell examples.
>
> One interesting problem has been the interaction from ooRexx with GUI objects
> which must be
> carried out on the GUI threads in Java (the "awt thread" or the "JavaFX
> Application thread").
> Although they got the necessary information about the architecture and what
> to do in ordert to
> become able to send messages on GUI threads, they kept running into problems,
> losing a lot of time
> (even months because they could not get it working in more complex programs).
>
> To make a long story short, I came up with a message based solution, that was
> very easy to
> understand and to employ for them. None of the students ran into the GUI
> thread problems since then.
>
> The solution is an ooRexx class for awt (the Java "abstract windows toolkit")
> named .AwtGuiThread
> and for JavaFX (a powerful GUI system) .FxGuiThread, both subclassing a
> common superclass
> .AbstractGuiThread. These classes allow one to send the ooRexx message
> runLater[Latest](GUIreceiver, messageName, arguments) which get queued and
> dispatched on the GUI
> thread later.
>
> The nutshell examples
> "bsf4rexx/samples/3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj" and
> "bsf4rexx/samples/JavaFX/javafx_update_GUI-from-non-GUI-thread.rxj"
> demonstrate how to employ this
> infrastructure. They have been working for years without a problem.
>
> While working on BSF4ooRexx I stumbled over an error (not having run those
> two examples for quite
> some time) which seems to indicate that ooRexx now creates an error when
> being used from different
> threads:
>
>
> F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\samples>3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj
> screenSize: [java.awt.Dimension[width=1920,height=1080]]
> winSize : [java.awt.Dimension[width=800,height=200]]
> xPos=[560] yPos=[440]
> a REXXEVENTHANDLER::actionPerformed - starting Rexx thread
> The SOME_REXX_CLASS class::updateGuiFromRexxThread - just arrived, GUI
> thread: 23808
> The SOME_REXX_CLASS class::updateGuiFromRexxThread - now running on
> thread: 7428
>*-* Compiled method "DELETE" with scope "Queue".
> 5727 *-* msgQueue~delete(idx) -- delete the guiMsg object
> 5637 *-* forward message "REMOVEMESSAGE" continue -- remove all GUI
> messages of the same name targeted to the same object
>207 *-* .AwtGuiThread~runLaterLatest(label, "setText", "i", str)
> Error 93 running
> F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\samples\3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj
> line 207: Incorrect
> call to method.
> Error 93.966: Incorrect queue index "1".
> a REXXEVENTHANDLER::windowClosing - release lock ('closeApp=.true') which
> will allow a blocked 'waitForExit' method to resume and return
>
>
