This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: suspend/resume nesting


On Wed, 21 May 2003 11:02:16 +0200
"Koeller, T." <Thomas.Koeller@baslerweb.com> wrote:

> > IMHO suspend/resume _is_ an ASynchronisation mechanism 
> > available in ECOS.
> > When you suspend a thread, you can't know in which state it 
> > is ! This is similar
> > to cancellation without synch points.
> 
> 
> No, if I am suspending the thread I am currently running in,
> I am perfectly aware of it's state. Suspending a different
> thread is of course a dangerous thing to do, and I never do
> that.
> 
> tk
> ----------------------------------------------- 
> Thomas Koeller, Software Development 
> 

The main purpose of suspending a thread via suspend ECOS
mechanism is to allow suspension of threads whose state is
not computable in advance. For instance, a debugging agent
that wants to suspend another thread.

I really don't understand why you wan't to suspend the thread
you are running in. It will much less esoteric to make that thread
going to sleep for an eCos flag, or any other synch primitive.

I really don't understand why you even need to look at res/susp.

For your information, other OS have the res/susp. Some portable
API, have not. And others stipulates that the suspend count is
a strict positive (Guess the most well-known ?).

So anything imposes your proposal. IMHO, the first contribution
of a kind of 'integrated debugging agent' will fix the res/susp.
interface usefull semantic

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]