Dear René:
On 07.08.2017 17:10, René Jansen wrote:
> Memory in multihreaded programs should be strictly guarded.
AFAIK I am doing that everywhere in BSF4ooRexx.cc (cf. e.g. RgfAcquireLock()
and RgfReleaseLock()).
> I know of a few debuggers that can set memory modification watches/traps, one
> is OS/2’s kernel
> debugger and the other is MVS’s SLIP SET trap mechanism. From what I see
> sometimes the register
> save area is clobbered (assuming you are linking correctly) and you could set
> a memory
> modification trap on the register save areas on the stack. Or use any kind of
> dump service to dump
> all stacks and investigate the ones of the errant processes. One more
> thought: if Rexx has a
> concurrency lock, what would be the point of traversing Rexx code in more
> than one thread?
There may be a multithreaded execution of Rexx programs and/or Java programs.
It should be (and has
been) possible to call from any Rexx thread Java and from any Java thread Rexx.
E.g. it has been possible in Java to use any number of RexxEngines (each
becoming a separate
RexxInstance) on the same thread or running on different threads concurrently.
> Wouldn’t it be beneficial to make sure your Java component only calls Rexx
> sequentially, so you
> can clean up everything between invocations?
Everything gets cleaned up between invocations by design (e.g. there are
reference counters
maintained for the objects in Rexx and Java registries that control the life
time of the stored
objects; the key for the Rexx registry - a directory - is the Rexx object's
identityHash value; the
key for the Java registry - a Map - is usually the Java Object.toString()
value, and if needed a
counter to make it a truly unique key).
> I did not read the whole thread very well, but does this also occur on Linux
> and macOS?
Yes.
(Tested it a few minutes ago on a fresh 64-bit Ubuntu ooRexx 5.0beta from
Sourceforge, August 1st,
and the latest BSF4ooRexx, hs_err_-log-file is on Dropbox.)
Best regards,
---rony
On 7 Aug 2017, at 16:55, Rony G. Flatscher <rony.flatsc...@wu.ac.at
<mailto:rony.flatsc...@wu.ac.at>> wrote:
>>
>> One hint: after installing BSF4ooRexx one can use the menu "BSF4ooRexx ->
>> Samples" to get an
>> explorer window. Then changing into "JavaFX" and loading "index.html" will
>> explain how to run
>> those JavaFX nutshell examples. You will see why I think it is so important
>> to get the JavaFX
>> support stable by finding the root cause.
>>
>> ---rony
>>
>>
>> On 07.08.2017 16:31, Rony G. Flatscher wrote:
>>>
>>> Dear Moritz:
>>>
>>> On 07.08.2017 15:02, Moritz Hoffmann wrote:
>>>> without going into too much detail I would say it's hard to track down the
>>>> root cause just from
>>>> the stack traces. It still looks like a memory corruption issue that
>>>> you're facing, especially
>>>> because it's not a deterministic failure.
>>> Yes, it definitely looks like it!
>>> :(
>>>
>>>> I don't see why you want to call into Rexx from different Java threads.
>>>> Rexx has a global
>>>> interpreter lock so you won't benefit from parallelism unless you have
>>>> fully independent Rexx
>>>> instances.
>>> The reason is simple: when employing a Java GUI, then it should be possible
>>> to write event
>>> handlers in Rexx and to interact with the GUI objects from Rexx.
>>>
>>> If an event is fired by Java, it will be fired on the GUI thread such that
>>> the Rexx code is able
>>> to directly interact with the GUI objects.
>>>
>>> If a Rexx programmer needs to interact with GUI objects from a non-GUI
>>> thread, then this would
>>> hang the GUI. Rather, one needs to make sure that the Rexx interaction gets
>>> carried out on the
>>> GUI thread sometimes later. This is
------------------------------------------------------------------------------
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
