How to MultiTask within a ABL Session

There is something inherently difficult about multitasking in a single threaded tool!

See http://www.oehive.org/MultiThread

In addition to the coordination problems which you are experiencing, the other problem with spaming a separate session is that you are paying a substantial overhead for starting up that session.

So, the first question might be, if you are going to wait for completion, why are you even starting a separate thread/process?

One approach that some people use is to spawn the separate process once and then use sockets to send messages back and forth.  Then, as appropriate, you can send a work request and wait for a response, although you probably want a timeout in case it never comes back.

Another is to recognize that this may be a perfect excust to implement a message bus using FUSE or Sonic and to make the other session a service on that bus.

Another is to decide that there is a possible client/server split in responsibility and that one can use asynchronous AppServer calls to provide a separate thread of execution without waiting on the result.  Note that "client" doesn't have to mean a session with a user sitting in front of it.

So, the first question might be, if you are going to wait for completion, why are you even starting a separate thread/process?

If I'm not mistaking the OP did NOT want to wait for completion - to work around the single threading.

Not the other way around.

I'm actually don't want to wait for completion of the process.     The  idea is to a have the program running on the the APPServer (always)  and checking a records on a table to spaewn a process.  I can be more the one process being spawned.

So, all of my proposed solutions apply.

Yes,    They do...

  Thanks,

        Andre

To keep it simple: Did you try to append an ampersand to the unix command you are executing to execute it in the background?

No I haven't!  What's the syntax for adding the ampersand?

No I haven't!  What's the syntax for adding the ampersand?

I'm not an UNIX expert, but probably something like:

DEFINE VARIABLE cCommand AS CHARACTER NO-UNDO.

ASSIGN cCommand = "_progres -b - your other parameters & ".

OS-COMMAND VALUE (cCommand) .

I'm not sure what the ampersand will do .. but i know that using the OS-command will wait for the completion on that session before it continues to the next progress session.

The ampersand in unix will effectively perform a no-wait on the Unix side, and so as far as ABL is concerned, the command has completed, even though it is still merrily running along. I also recall having used "nohup some/command &" in the past, but I'm not sure what the nohup gives you. I suspect google man nohup will tell all ....

-- peter

I'm not sure what the ampersand will do .. but i know that using the OS-command will wait for the completion on that session before it continues to the next progress session.

The Ampersant should run a Unix command in the background.

I think Mike has the correct answer, although your question does seem a bit ambiguous.

The ampersand sends a process to the background in Unix.  Basically, it disconnects the i/o streams from the terminal, which makes the terminal think that the process has completed immediately.

Notice that these statements return before the sleep command actually completes:

UNIX SILENT VALUE("sleep 9999 &").

OS-COMMAND SILENT VALUE("sleep 9999 &").

Thanks Guys!   I think that's will work for what I want to accomplish.

Note that putting the second session in the background makes it difficult to get any output from it.  One can do clunky things like write to a file, with all the checking and verification that implies, but you can't pass back any Progress artifacts like records and TT and such.  This is possible with the other techniques mentioned.  You also have no ability to guage the status of the other process.

Right.  He didn't say that the sessions need to communicate with eachother, but if so he could do low level IPC using sockets or named pipes or high level like the service buses that you mentioned previously.

You also have no ability to guage the status of the other process.

You may not like it, but in many cases the DB is absolutely sufficient for status reports.

We use internal procedure bgcore.p to control number of background processes.

Each bg process calls this procedure every minute (if idle). If process was closed by error/kill it will be respawned again.

To identify number of bg processes we check _Connect table.

Procedure returns "STOP" to stop current process (w/o killing).

File bgparam.cfg is method to controll/shutdown bg processes.

CheckLock procedure used to identify fact that bg process is blocked by user.

For example bg process is needed to recalc some document and change status, but user locks it. In this case we kill user process.

Without looking at the code, this reminds me of an option which I neglected to mention, which is to use a shared daemon process for your background processing with work requests being created in a DB table and the daemon checking periodically for work to do.  This can work well for things like background reports, but is not so good if you need to get results back to the initiating session.