While going thru the execution patterns that are present when this problem
occurs the following can
be observed (seems that this must be present to get that error from time to
time):
* there are at least two threads active, one created by Java (the application
thread, the JavaFX
version of awt-thread for processing [GUI] events) where the creation of
Java objects and
callbacks to previously defined factory-Java-objects that are implemented
in Rexx (e.g. when
filling a JavaFX Table) cause a "flurry" of Rexx objects to be created in
that JavaFX
application thread living for a very brief time, only for the duration of a
Rexx method that
gets carried out,
* the callback from Java to Rexx in the JavaFX application thread will cause
a flurry of
ThreadAttach() and DetachThread() before returning from Rexx to be carried
out on the Rexx
interpreter instance (RIIs),
* there are a few additional RIIs created for each FXML file where JavaFX
uses javax.script to
create a RexxScript instances (each causing the creation of a proper RII)
to deal with a
FXML-defined GUI scene object causing creating Rexx objects and call-backs
from Java to Rexx
o these RexxScript objects will have .input, .output, .error, .debuginput
and .traceoutput
redirected to Java supplied System.in, System.out, System.err objects,
so any activity in
these monitors will cause (possibly a flurry of) calls to Java and
callbacks from Java
HTH,
---rony
On 12.03.2017 13:41, Rony G. Flatscher wrote:
> Has there been any success in tracking this down so far? Is there anything I
> could/should do in
> the meantime to help solve this problem?
>
> ---rony
>
> On 22.02.2017 21:28, Rony G. Flatscher wrote:
>>
>> Is there anything I could do to provide information that could help solve
>> this problem, or is
>> enough already known?
>>
>> ---rony
>>
>>
>> On 22.02.2017 15:48, Rony G. Flatscher wrote:
>>>
>>> On 22.02.2017 15:44, Rick McGuire wrote:
>>>>
>>>>
>>>> On Wed, Feb 22, 2017 at 9:33 AM, Rony G. Flatscher <rony.flatsc...@wu.ac.at
>>>> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>>>
>>>> O.K., this may be a little bit weird: I can manage to have the test
>>>> code run without an
>>>> exception, repeatedly!
>>>>
>>>> Background: in the native code I have many, many output statements to
>>>> stderr for debugging
>>>> (tons over the years, controlled by defines) in the form of, e.g:
>>>>
>>>> fprintf(stderr, "...\t\t\t\t\targ(%d)=[%s]\n", idx,
>>>> rtc->CString(rtc->SendMessage0(rtc->ArrayAt(ra,idx),"STRING")));
>>>> fflush(stderr);
>>>>
>>>> Changing the above output to:
>>>>
>>>> fprintf(stderr, "...\t\t\t\t\targ(%d)=[%*.64*s]\n", idx,
>>>> rtc->CString(rtc->SendMessage0(rtc->ArrayAt(ra,idx),"STRING")));
>>>> fflush(stderr);
>>>>
>>>> makes the test code run it seems!
>>>>
>>>> btw, thjis is also going to add two entries to the local reference table
>>>> each time you do this.
>>>> The table could end up getting quite large if you have a long running
>>>> call. If you're only
>>>> doing this for debug purposes, it probably doesn't matter.
>>> Yes, it is for debugging only. ---rony
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
