--- In cheapthreads@yahoogroups.com, "seabueg" <Josef.Bueger@e...>
wrote:

<snip>

> The documention (somehow also mentioned in newsgroup) could be
better.

What sort of improvement would you like to suggest?

> But during the first testing I have missed something like
> a "watchdog". No matter you are working multi threaded/single
> threaded applications the basic platform should/MUST have control
> possibilities in case of something ended up in a infinitive loop or
> something similar.
>
> In case of you could already provide something similar, I
> appreciate... Properly something could be done already by reserving
> the hightest priority to a supervision process (i.e. exit after n-
> seconds seconds scheduler not running due to ...).

If a thread gets caught in an endless loop, there's nothing that
Cheap Threads can do to detect or terminate the loop, because the loop
prevents the scheduler from regaining control. Unlike conventional
threads such as POSIX threads, these threads are synchronous. They do
not interrupt one another. A thread has to return control to the
scheduler before another thread (or the scheduler itself) can run.

Given the way Cheap Threads works, there's no *portable* way to
eliminate this problem.

There may be a solution within a particular platform. For example,
you may be able to trap a timer signal generated from the hardware.
Let your signal handler increment a counter, and if the counter ever
gets too big, do a longjmp into some kind of abort routine. Meanwhile
some high priority thread, or better yet a user exit, resets the
counter to zero whenever it gets a chance.

That much you could do without modifying the Cheap Threads package
itself. You might also be able to modify Cheap Threads for a
specific platform, but I don't know what such a modification might
look like.

So far I have assumed that the infinite loop occurs within a single
invocation of a thread. If the infinite loop involves multiple
invocations of a thread, then the scheduler is part of the loop. In
that case you have a chance to detect the problem by some kind of
counter-checking scheme as described above.

> I have encountered the problem as I have tried to implement ~10
> threads including a timeout service for these applications.
Properly
> a timeout server could be imlemented per default also (reply
> suggested message to a thread after supplied timeout, cancel,
> restart, ...).

I'm not sure what you're saying here. The Cheap Threads scheduler
provides a timeout facility as a compile-time option. However this
facility depends on the scheduler's regaining control from the
threads. If a thread never returns control, the timeouts won't do
anything for you.

> I was just playing for a couple of yours, nevertheless I found it
> very useful and awaiting an answer now.
>
> It seems that you are personally an experienced designer, do you
have
> an API to other-vendor RTOS platforms?

I've never worked with real time or embedded systems, and I don't
have any particular APIs for them. My experience has mostly been in
batch applications for businesses. In fact, on the job I have spent
more time writing COBOL than writing C. Cheap Threads has been a way
for me to play with something I didn't know anything about, and it's
very different from anything I've ever done professionally.

> Best regards
> Josef

Thanks for writing.

Scott McKellar mck9@...
http://home.swbell.net/mck9/ct/