Peter Fitzsimmons wrote on 29 Dec 1994 to Ruud Senden:

 PF> This is a very odd use for a pipe.  Unnamed pipes were
 PF> provided primarily for separate _processes_ to send data to
 PF> each other,  ala Unix stuff. 

 PF> They are slow and cumbersome in the eyes of a Thread,  who
 PF> has more flexible/powerful/faster IPC mechanisms available. 
 PF> In your case,  I would have used queues (see
 PF> DosCreateQueue()).

Well, I just needed something to communicate between the two threads, and
unnamed pipes seemed the simplest to me. 
This is the first time I really work with multiple threads (I have looked
at it before, but haven't done much with it), so it is mostly new to me.

I even wrote the same kind of program with only one thread, but now I want
to convert it to a PM program, so it has to respond quickly to system
messages. Also I want to support multiple sessions (it is a program which
does things to Communications Manager/2 sessions) in one program, so I
start a seperate thread for every session. In the original text-mode
version the program could only do one session, so it had to be started
seperatly for every session. 

 RS> Since I also have to do other things in both threads, 
 RS> I don't want the DosRead()-call to block.

 PF> If you ever find yourself saying a thread has "other things
 PF> to do" it means you need another thread!   When nothing is
 PF> happening,  ALL threads should be blocked on a system call.

I will think about this. I think I can do this at least in the thread which
uses the hllapi()-calls. The reason the call shouldn't block is that when
key-interception is on, I have to respond immediatly to a keypress in the
session. Until now I did this in the same thread (because I did it this way
in the original program), but I can use another thread for this perfectly I
think.

In the main thread it is more difficult, but I think it is also possible.
One thread which processes the system messages, another one to write the
status information received from the session-thread to a listbox and
eventually uncheck a checkbox or something.

Regards, Ruud 

--- timEd/2 1.00