Laurence, thank you for reasoning. Most things are congruent with my ideas, but I think that you have one circumstance not in view.
You shouldn't be continously polling the Vio cursor position, it's uneccessary. The only time you need to know if the Vio cursor has moved is following the completion of a command that produces no output on stdout.
If a VIO program waits for user input (e.g. a VIO-based editor or a menu program like DFSEE), I need a loop with continous querying. After again thinking about the problem, I have got this result: The PM editor has to send two kinds of queries to the helper:
1. A single query after a current command execution ends and a prompt is shown again: "Please tell me if VIO (cursor position) has changed and end the loop, if it is running".
2. A continous query via thread loop: "Please observe the VIO window and tell me immediately if VIO has changed."
The continous query is only sent to the helper if no stdout is shown for a specific time, e.g. 300 or 400 ms.
An option to optimize is to check whether the output contains Returns without Carriage (^M only without ^J). This output is typical for progress bars of stdout programs. In this case, a continous VIO observation is not necessary in my opinion. The editor knows it already.
This is all quite simple to program for me, because a lot of stuff can be reused: For the post from the PM window to the helper, I can use the semaphore and Shared Memory I use for the Ctrl-C exception. Then in the PM editor I have one unused thread left which starts the helper. I can add here a wait for semaphore loop. I have not to submit any data from the helper to the PM editor, I have only to wait for the semaphore event "pop VIO window now". This semaphore event is used in both cases 1. and 2.
So I will need a new semaphore. I will generate the semaphore fin the PM editor, the pointer value is submitted via commandline parameter to the helper again. Then I need a new thread in the helper executing the loop.
Two minor questions:
In the helper, I can recreate the thread if needed or suspend/resume the old thread. (Any ideas what is to prefer?)
When creating the new second semaphore, I hope that it is allowed that the receiver creates the semaphore? Normally the sender creates it. The way via commandline parameters to submit the pointer value is very easy for me.