In a message dated 09-26-99, Peter Knapper said to Mike Ruskai about "hstart
wget?"

Hi Peter,

 MR> eight simultaneous transfers (using the threading support 
 MR> of OREXX).

PK>This sentence caught my eye, I have not dabbled in OREXX too much
PK>(actually I have tried to avoid anything to do with OBJECTS until I 
PK>absolutely HAVE to......;-)),

If you want to use native multi-threading in OREXX you HAVE to.

PK>but can you please elaborate 
PK>on how OREXX implements Multi-threading? Is each thread 
PK>under explicit coder control (IE can a control thread 
PK>stop/start other threads?), or is it "dynamic" threading 
PK>within OREXX that does not allow explicit thread control? 

It is quite simple really. An object class can have one or more methods that
run in secondary threads. These are identified by the REPLY statement. This
statement sends the nominal result of the method call back to the caller,
and then allows the method to continue. This has the effect of resuming the
caller's execution and allowing the method to continue in parallel. The
obvious implementation is to use OS/2's threading capability.

You get to control thread creation in your code. You can have as many
threads in your address space as virtual storage constraints and the system
thread count constraint permit.

As to synchronizing concurrent threads, that is up to you. The simplest
approach is to add an attribute to the object class and have the
asynchronous method check to see if some other thread has requested that it
terminate. Basically, the other thread sets the attribute to some value and
when the thread inside the owning object checks the attribute it takes the
appropriate action.

A somewhat slicker method is to use the event semaphore support in REXXUTIL.
This is more idiomatic OS/2, as it eliminates polling of attributes. You
simply wait on and post the shared semaphore in whichever threads you want.

Regards

Dave

___
 * MR/2 2.25 #353 * "More hay, Trigger?"  "No thanks, Roy, I'm stuffed!"

--- Maximus/2 3.01
267/200
45