Michael Schnell wrote: > > >9) Or is my approach of multiple processes otherwise flawed? > In Linux the communication between processes is really fast, cheap, easy > and versatile. > > You can e.g. use pipes/queues (e.g. named pipes in the file system or > system 5 message queues). > > In many cases you don't need threads to wait for data from such a queue > as you can use appropriate system library calls like "select()" or (the > new, more advanced way) (e)poll() (which despite of it's name does not > do any actively spinning polling) to schedule your reactions on several > events thrown by other processes. In Linux "everything is a file", so > handling such queues (and IP-sockets, hardware ports etc) is done using > the same paradigm as with handling normal files.
It's usually not as cheap as threads because you have to design and implement a protocol for every little thing that's communicated. That takes time, and it also uses more code space. But it's far cleaner and easier to debug separate processes. And as Jan noticed, if you want to install just the components you need for different configurations, that's easier with separate processes than a single giant application. -- Jamie _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
