pf@artcom0.north.de (Peter Funk) (10/04/90)
johnk@telxon.UUCP (John E. Kabat Jr.) writes: [...] jk> Sample code (pseudo code) jk> while (1) jk> { jk> check I/o with no wait jk> check IPC queue with no wait jk> if (no input) jk> nap(100) jk> } Uhh... busy wating. :-( One of the basic rules in programming on a multitasking OS is : Don't use BUSY WAITING. Normally the 'select(S)' (resp. 'select (2)') system call is intended for problems, where one process has to wait for several independent input channels. In your example of course you can't use 'select', since 'select' is not applicable to IPC. May be others also don't want to rely on such a dubios thing as the 'select' system call. (The 'select' system call is implemented in SCO Xenix since release 2.3., earlier releases have no select. 'select' also requires a little bit of support within the device driver, which makes things worse, when you are relying on third party device drivers for some kind of exotic plug-in board: A very common situation in the PC market) Fortunatelly there is another more portable approach to avoid busy waiting : Have a seprarate process for each logical input channel. Your example above may be coded as shown below (also pseudo code used here) : me=fork(); if (me == 0) { while (1) { /* I/O client process : */ Wait on input (Blocking Read); Send signal to the other process; /* If the read input data should be transmitted to the other process this may be done here (e.g. using a pipe) */ }; } else { while (1) { /* Master process : */ Wait on IPC Queue; if (errno = EINTR) { no IPC occured : Read from I/O channel } else { consume IPC data from queue } } }; Look's a bit more complicated, although I've left out much of the usually necessary error checking. But the use of "busy waiting" or "select" are both completely avoided. To make this approach really work, you should spend some careful thoughts on the following topics : * Think about the 'copy on write' strategy for shared memory pages of forked processes. The I/O consumer processes should be forked before you malloc megs of dynamic structures. * Think about a special software layer encapsulating this kind of process communication. So you may use 'select' or some other kind of not so portable hacking inside this layer, without having a great impact on your complete software package, when you later ran into the need of having to port your package to another less comfortable platform. One way to think about process communication on a higher and more abstract level is the so called client/server approach. There are commercial packages available, which make the developers task to deal with with IPC much more easier. (Some people told me, that they think: "System V IPC is one great bug" ;-) * On SCO Xenix, Sys V shared memory in conjunction with Sys V semaphores provide a really fast way of inter process communication. (Much faster than pipes). We have successfully used the approach described above in our home grown window system. (Which is a "little bit" smaller, faster and easier to use than X11 ;-)) -- Peter Funk \\ ArtCom GmbH, Schwachhauser Heerstr. 78, D-2800 Bremen 1 Work at home: Oldenburger Str.86, D-2875 Ganderkesee 1 /+49 4222 6018 (8am-6pm) >> PLEASE Don't send BIG mails (oversea) ! I've to pay for it : $0.3/kB Don't use the bang path of this news article for mails (They will bounce). Only the address 'pf@artcom0.artcom.north.de' will work. Thank You ! <<