Michael Schnell wrote: > So I don't understand why you bother about "real" threads at > all. some 50 Lines of C code will "schedule" your "threads" one > after the other as part of a single application/process, all running > on the same stack,
That's fine if the code is simple enough to be event driven and always returns to your event scheduler. But some code looks like spaghetti that way, and then it's better to use scheduling points inside functions, rather than having to return from the whole function stack after recording local state into a state structure. Of course you can still do that without a kernel :-) For more complex real-time stuff, often you have priorities, locking between threads, and priority inheritance to avoid priority inversion. The simple event-driven loop gets complicated with priorities, when one event handler needs to interrupt another event handler in the middle. The loop starts to resemble a full blown kernel scheduler... -- Jamie _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
