Some senseless babbling from Peter Knapper to Mike Ruskai
on 09-26-99  11:48 about hstart wget?...

 PK> Hi Mike,
 
 MR> I'm currently working on a design that will allow up to 
 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......;-)), but can you please elaborate on how OREXX
 PK> implements Multi-threading? Is each thread under explicit coder control
 PK> (IE can a control thread stop/start other threads?), or is it "dynamic"
 PK> threading within OREXX that does not allow explicit thread control? 

It's nothing as direct as using the OS/2 API.  The way to run a separate 
thread is to issue an early reply from an object method (and perhaps also a 
routine), rather than returning, allowing the method to continue running on 
a separate thread.  The reply may pass data, but the subsequent return that 
ends the method can return no data (for obvious reasons).

I've already used this for monitoring the transfer with the urlget.cmd at 
Hobbes.  I'm not sure if there's a better way, but I've taken to using 
queues to exchange data between different threads, since there seems to 
never be any conflict when queueing and pulling from the same queue at the 
same time.

What I'll end up doing is using a separate thread to write all information 
to the screen, which will "poll" all the information queues at a set 
interval (i.e. check for items in the queues, and if present, retrieve them 
for action).

 PK> I have implemented multi-threading in C many years ago, and have a
 PK> project for Rexx that could use it nicely, but I may have to dig more
 PK> into OREXX to get to grips with the requirements for using it.

You'll have to modify it considerably, because the threading is not quite 
direct, as I said.

But it provides for some interesting possibilities.  Here's a brief example 
to demonstrate the concept:

/* Simple threading example */
call RxFuncAdd 'SysLoadFuncs','RexxUtil','SysLoadFuncs'
call SysLoadFuncs

.local['DQ']=.queue~new
.local['CON']=.stream~new('stdout')

scrupd=.ScreenUpdater~new
scrupd~StartUpdating

do i=1 to 1000
    .dq~queue(i)
end
.dq~queue('EXIT')

do until .dq~items=0
    call SysSleep 0.10
end

exit

::class ScreenUpdater

::method init
expose row col
call SysCls
call SysCurState 'off'
call SysCurPos 11,0
.con~~charout('Data received: ')~flush
parse value SysCurPos() with row col

::method StartUpdating
expose row col
reply
done=.false
do until done
    if .dq~items>0 then do
        data=.dq~pull
        if data='EXIT' then done=.true
        else do
            call SysCurPos row,col
            .con~~charout(data~right(5))~flush
        end
    end
end
say ''
return
/* end example */

As might be apparent, there's no way to kill the thread from without.  It's 
important to establish a signal for termination.  In the above case, it's 
merely stuffing the queue with 'EXIT', then waiting until the queue is 
empty before exiting.  If you remove that wait, you'll notice that you're 
back at the command prompt while the thread is still running and updating 
the screen (it is, after all, a thread of the current command processor's 
process).

Mike Ruskai
thannymeister@yahoo.com


... Cannibals don't eat lawyers. Professional courtesy.

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
267/200
45