Curtis Olson wrote: > This is a little off topic, but I don't know where else I can find a > stronger knowledge pool. :-) > > I am working on some code that needs to read and write from a serial > port and has to write vast quantities of data ...
Curtis, I wouldn't use threads, but a whole separated process. Use circular buffers in shared memory to transfer data, and semaphores to coordinate data transfers in/from these buffers. That way your main process only needs to do non-blocking memory to memory transfers. The serial coms process can handle all the quirks of the protocol, create separate Tx and Rx threads if necessary, decide when to drop data, block itself when needed etc. One of the advantages of using a separate process vs threads in the main application is fault isolation. (1) The unavoidable crashes during development may bring down only this process, allowing you to continue by restarting only this part and not the whole application. The same applies if you want to try a different version. Stop the subprocess, start a new one. Hope this helps, Roberto Waltman. (1) I worked for a company whose coding standards required a manager's waiver to use threads, because of the difficulties of debugging complex multi-thread applications where every thread can corrupt global data. And the fault isolation. ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
