The more I think about this the less happy I become.

Rony's solution would also mean that all RDBMS interaction would have to go through the daemon as it sits on the thread where the connections work, and so that is not the main thread the interpreter uses.

I don't really understand how RxFuncAdd works.  Could one invoke a function package multiple times from different threads.  Would that work?  Or perhaps only where the package is thread safe (a term I have heard, but don't really understand)?

Anyway, thank you both for your responses. 

Jon

On 31 May 2010 12:19, Sahananda (Jon) Wolfers <sahananda@windhorse.biz> wrote:
Hi Mark,

I've done a bit of experimenting and I'm sorry - I spoke too soon.  It would require a complete bottom up rework to make the executeasynch method work for me, as the dialog then runs in a seperate thread from the main body of code.

This is not your problem, but I will explain.

I have a library of common routines which establishes the environment for my scripts, establishes the connection with the RDBMS and makes use of that connection to provide various services.

I then have a number of scripts, all of them dialogs which ::require that library. 

These dialogs are started with execute and make use of the established connection to the database.

Only in one case, do I need while the dialog is active, for it to watch for files appearing and act on them when they do, so I run asynchronous methods within that dialog to initiate a regular watch for files & then kick off the processing of those files when they appear.

Using execute to launch the dialogs, the dialog is run in (or is it on) the same thread that the connection was established with in the required common library.

If I was to switch to executeasync I could then manage to make the connection for that one problem case, but would lose the connection for the many other interactions with the rdbms.

What I would ideally like is the ability to interact with the database, no matter what thread I am running on, and perhaps Davids work will provide this.

Until then, I think the simplest way for me to go would be to provide a daemon as Rony suggests and let it handle the interaction, but it is sad to need that extra layer of complexity.

thanks,

Jon



On 31 May 2010 11:04, Sahananda (Jon) Wolfers <sahananda@windhorse.biz> wrote:
Hi Mark,

first of all, thank you to you and Rony for your examples and workarounds. 

I had just returned from a month away to a mountain of emails and was in a sort of despatch them quickly without thinking about them enough mode. 

Both methods look really good.  I tend to code down grooves and I have used executeasynch in my code, but tended to think of it as only useful for splash screen type dialogs.  You have opened up my mind a little and now that I see it it is obvious.  As usual, you have put a lot of work into the example, for which I thank you.

As far as backwards compatibility goes, it looks to me like I did something rather unorthadox here, and had I coded it sensibly it would work on 4.0.0.  I'm not sure now who received advice from me on this, but I guess the same thing stands there, they have used the mechanism in a way that was not intended.  It seems to me the onus is on us to rework our code to comply with intended usage of the tools.

thank you for your help,

Jon



On 30 May 2010 17:23, Mark Miesfeld <miesfeld@gmail.com> wrote:
On Sat, May 29, 2010 at 10:25 PM, Sahananda (Jon) Wolfers
<sahananda@windhorse.biz> wrote:
>
> I can't offer you much on this, but you ask
>
> On 28 May 2010 17:24, Mark Miesfeld <miesfeld@gmail.com> wrote:
>>
> ...
>>
>> 2.)  This is not necessarily a bad thing, but it is different
>> behavior.  Is it sufficiently different to be a problem?
>>
>
> and I would say that if I understand it correctly then it would definitely
> cause me a problem.
>
> The old behaviour, although it feels wrong, has been a bit of a godsend to
> me.  Rexx\SQL can only work in the thread in which the library has been
> loaded.  Therefore, where I want to access it in an oodialog method, I go
> through a rather hideous kludge of passing control to a method 'in' the
> original thread by programmaticaly editing a hidden edit control with a
> connecteditnotify watching it.

Well, that's disheartening.

My post wasn't really about the event handler methods running on a
different thread than the main thread, it never occurred to me that
people would write programs relying on that.  (My other post has an
example program that doesn't rely on it.)

The post is really about the behavior when there was a syntax
condition, or other condition raised in the event handler method.  In
3.2.0, this would normally print out the condition information and
cause the ooDialog program to end.  Whereas in my current ooDialog, in
trunk, it would print out the condition information and the dialog
would continue to execute.

What I was worried about was the difference in the program ending
versus continuing to run.

What's disheartening is that I've spent a lot of time and effort
struggling to maintain backwards compatibility in ooDialog with what I
want to do / to implement in an improved ooDialog.  It seems that,
that just isn't feasible.

I'll probably post under a different subject heading to explore that further.

--
Mark Miesfeld

------------------------------------------------------------------------------

_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel