On Mon, Jun 18, 2007 at 01:32:21PM +1000, Murray Taylor wrote: > I can only think of one other point for this... > Interrupt latency. Depending on what you are attempting to do, > the variable nature of interrupt responses could be an issue. > I.e. if the system becomes io bound during a data capture cycle, > and something occurs that requires a response within a very narrow > window, it is possible to miss the window due to other interrupt > processes running. > > For this reason, robotics systems often run on highly optimised > single process systems where there is a 'guaranteed' poll cycle > and / or a very minimal defined interrupt system with minimal > overheads.
I suspect that increasing concurrency capability in the near future will change that a fair bit. It'll probably start with highly concurrent embedded and realtime OS development (he said, wildly guessing) and seep out into other areas of computing from there. -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] awj @reddit: "The terms never and always are never always true." _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"