As always, delighted by your interest. Yes, I'm quite aware of forking a new process and executing new code. And yes they are different and your "terminology matters" is important. I did a fun program to play with modem control lines of the old standard UART, actually very deep control of the UART registers and terminal IO filtering. I used the fork and pipe trick to create a listener waiting and an active process. Played with pseudo terminals. I've played with IPC message queues and semaphores. The crazy and disappointing thing about the RS232 UART was the Linux driver UART fifo setup was broken and not completely fixed until kernel 2.6 or 3.0?. I do know the unnamed semaphore initialization can be configured for between threads or between processes. And are vastly simpler than IPC semaphores. My manpage says to link with pthreads or rt so they are probably in rt, and conforming to posix.1-2001. I guess my interest in the UART programming was using hardware (modem control) interrupts with serial port automation. Everybody thinks RS232 is 2 wires plus ground now. Others were playing with it, but Theo. Tso. the driver maintainer said it was a bad idea, but then it was a bad driver too. Current USB ports are fast, but not an old guy's idea of an industrial controls interface. Iznogoud wrote: > Rick, > Threads are not "forked()" they are "spawned" and in this case, in my opinion, > language matters because something that is forked is practically gone down > the forking path and is on its own. Threads are still children of the main > process, and can detach or reattach. If these concepts are not clear, you can > get really confused while writing code. > > The mutexes and semaphores are not a POSIX thread thing, but a general > construct. I recently tried, and succeeded, implementing a distributed parallel > mutex and semaphore. The concept is generic. > > Semaphores/mutexes are just one way to synchronize threads. As I had said in > the past, I use pipes with a select() system call to monitor the pipes for > changes to achieve the same effect more generically. I did this for a sound > application, which requires good real-timeness. I can share pseudocode and > timing diagram if anyone is interested. > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list >