On Tue, Mar 14, 2017 at 11:24 AM, Rony G. Flatscher <rony.flatsc...@wu.ac.at
> wrote:
> 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),
>
> The flurry of AttachThreads() and DetachThreads() might be the cause of
the GC issues. When a DetachThread() occurs, the GC protections on any
objects returned by call on that context are lost.
Rick
>
> - 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
> - 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> 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
>
>
------------------------------------------------------------------------------
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
