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."
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to