This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: suspend/resume nesting
- From: "Koeller, T." <Thomas dot Koeller at baslerweb dot com>
- To: 'Eric Donnat' <e dot donnat at silicomp dot fr>
- Cc: "ecos-discuss (E-Mail)" <ecos-discuss at sources dot redhat dot com>
- Date: Wed, 21 May 2003 13:15:18 +0200
- Subject: RE: [ECOS] suspend/resume nesting
Eric,
my intention was to make a proposal for an improvement
in a particular field. At least I see it as an
improvement, others may of course disagree (that's why
I posted it here).
I do not think that 'don't do that' is a valid response:
this implies subdividing the API into a set of functions
that may be used and others that may not. To a novice user
this could be a bit confusing. If the user is not supposed
to call a particular function, then the API must not expose
it to him.
The scheme I described and used in my program is perfectly
valid, it does not use anything that is not in the official
API, and so it should just work. You are vigorously defending
your point, but I still cannot see what benefits I get by
disallowing negative suspend counts.
tk
> -----Original Message-----
> From: Eric Donnat [mailto:e.donnat@silicomp.fr]
> Sent: Wednesday, May 21, 2003 11:39 AM
> To: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] suspend/resume nesting
>
> 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
>
-----------------------------------------------
Thomas Koeller, Software Development
Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany
Tel +49 (4102) 463-390
Fax +49 (4102) 463-46390
mailto:Thomas.Koeller@baslerweb.com
http://www.baslerweb.com
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss