1) Design you OS so it supports pipes that output data when someone is logged on, but gobble it up when they are not. Put .S amd ." where required in the tasks code; log on when desired and see what is happening.
2) Have words that print a detailed desription of what the thread is up to.
3) Have an ABORT word that saves as much detail as possible in the user area so 2) can do it's job well.

Regards

Glenn Dixon wrote:

> The recent multitasking discussion brings out how difficult it is to debug even simple things such as unexpected stack actions when the functions are in a different thread/callback. While SLEEP could have been tried within the Forth console window, not all functions (callbacks especially) can be invoked manually. Event messages might be an example.
>
> Does anyone have any debugging tips that have helped them debug code in callbacks and other threads? I've resorted, in some cases, to writing stuff to log files, and find this awkward and time consuming compared to debugging from the forth console. One of the real problems is that I can't confirm through testing that my callback code is bug-free--there may be a problem lurking in there, but I can't easily set up callback conditions to reveal it.
>
> Help, anyone?
>
> Glenn Dixon
>
>
> _______________________________________________
> Sftalk mailing list Sftalk_at_forth.com
> Visit Sftalk on the web at http://www.forthinc.com/mailman/listinfo/sftalk
Received on Wed Jul 05 2000 - 15:46:39 PDT