Swat tracks all running threads. Suppose your application is called
"myapp" and has both a process thread and a ui thread. Your Swat prompt
may look like
[myapp:0] 73 =>
or like
[myapp:1] 74 =>
Notice the integer in the brackets after the name of your app. These
are your thread numbers: thread 0 is always your app's process thread,
and thread 1 is your app's ui thread. (If your app dynamically creates
more threads, they will be numbered consecutively from 2 on.)
To switch threads in Swat, use syntax like:
[myapp:0] 75 => sw myapp:1
to switch from your app's process thread to its ui thread, or
[myapp:1] 76 => sw myapp:0
to switch from your app's ui thread to its process thread.
> It seems that now I have to go from the beginning till end of one function
> at a time.. Is this how GEOS functions run in real life, no context switch
> in the middle of methods/functions? Then how interrupts could work :(
As for GEOS's context switching between threads: GEOS can context-switch
between any two instructions. And GEOS does of course support interrupt
behavior -- for example, the keyboard and mouse input drivers generate
interrupts, which GEOS responds to, leading to the fast response times
that GEOS users experience. [For more information on threads in GEOS,
see Appendix B in the Concepts book: "Threads and Semaphores."]
The behavior you're observing could be due to sending a message: When
you send a message to an object that's run by a different thread as the
currently-running thread, that message is placed on the queue, so may not
be processed until after your current method is finished.
To fully understand what you're seeing, though, you'd have to show us
what code you're running, what threads the code runs in, etc.
> "Warning: Unable to install breakpoint: Access denied":
> The warning on the subject line.. that's what I get when swat changes
> threads after some func. It stops there, so what access is denied ??
Are you debugging on the target PC, or on actual hardware? If the
latter, then the warning means that Swat can't install a breakpoint
because the code is in ROM. If the former, then it's hard to tell
what the warning might mean -- again, we'd have to see your code,
see where you're installing the break, etc.
Hope this helps,
Paul.