[Xenomai-help] Re: Re: Re: A fairly small rtnet/Xenomai

[Xenomai-help] Re: Re: Re: A fairly small rtnet/Xenomai

[M. Koehrer]

Hello Philippe, 

> The important issue to check is the above one. Please try calling
> rt_task_delete(NULL), and in a second test, rt_task_suspend(NULL),
> instead of letting the thread routine return. TIA,
O.K, here are the results:
I have placed rt_task_delete() at all possible positions in realtimetask().
The system freezes when I place rt_task_delete() after the printf() statement.
At all other positions (after system(), after rt_task_sleep()) the system does not freeze.
I get the very same results when I use rt_task_suspend() instead of rt_task_delete().

It means, that the printf() call causes the freeze.

Regards

Mathias

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  44,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

[Xenomai-help] Re: Re: Re: A fairly small rtnet/Xenomai

[Dmitry Adamushko]

On 21/12/06, M. Koehrer <mathias_koehrer@domain.hid> wrote:
> Hello Philippe,
>
> > The important issue to check is the above one. Please try calling
> > rt_task_delete(NULL), and in a second test, rt_task_suspend(NULL),
> > instead of letting the thread routine return. TIA,
> O.K, here are the results:
> I have placed rt_task_delete() at all possible positions in realtimetask().
> The system freezes when I place rt_task_delete() after the printf() statement.
> At all other positions (after system(), after rt_task_sleep()) the system does not freeze.
> I get the very same results when I use rt_task_suspend() instead of rt_task_delete().
>
> It means, that the printf() call causes the freeze.

just to be sure.

Could you try with other secondary domain calls (instead of printf() )
: write() (open/close as I suggested before) or even getpid() ?

(1) instead of the last code line (printf() after rt_task_sleep() ) ;

(2) put it after system(). Does it still prevent a PC from hanging?


-- 
Best regards,
Dmitry Adamushko

[Xenomai-help] Re: Re: Re: A fairly small rtnet/Xenomai...

[M. Koehrer]

Hi Dmitry, 

> 
> > As this is hard to understand, I strongly recommend that there is Xenomai
> support
> > for this! I.e. a Xenomai API that can be called with a (callback-)function
> pointer and
> > a user data pointer.
> > When a (realtime) thread calls this function, the real time thread is
> blocked.
> > The callback function is then called from a safe context and
> > after exit of the callback function the real time thread is resumed.
> 
> I haven't got your idea. Did you get the cause of the problem with fork() ?
Yes, I think I got it (more or less).

However, as a typical user of a OS I do not want to take care of this
very specific things. I want to call an OS-API that is doing the job for me.
I.e. in my example, I want to call an API that allows me to execute whatever
external application without any risk and side effects.
>From the functional point of view I want to use the "system()" call.
When it is not save to call system() directly (due to all the things that have been
discussed), I think it is important to document this (e.g. in the Wiki) _and_ to
provide an easy usable replacement for it, i.e. something like a rt_task_system()
that does all the required things internally for me and behaves on the functional side exactly
like the standard system() does.
The Xenomai Native example is a very good example for a cleanly designed API that
can be easily (and nearly intuitively) used. 
Any workarounds (I call it workaround as the intuitive, straightforward approach is not possible)
that are required to get a problem solved, weakens the whole OS (Xenomai).

Regards

Mathias

-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  44,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

[Xenomai-help] Re: Re: Re: A fairly small rtnet/Xenomai...

[M. Koehrer]

Hi Philippe, 

I agree. To fix the root cause is actually the very best to do!
This eases the life of users and developers.

Regards

Mathias

> 
> Sorry, but no, no way, I won't merge anything like this, ever. This is
> the wrong way to go. The right way is to fix the COW issue at kernel
> level - probably the I-pipe has to provide the required support -
> because this is where those dirty details belong to. This is definitely
> not an API issue, because you just cannot tell application developers to
> care about arch-specific VM issues when using a so-called generic API
> that has to work the same way on all archs (e.g. MMU-less platforms
> don't care about this, others would). What could be considered as a
> bearable limitation right now must not have any impact on long-term
> principles, and the API stuff belongs to that category of issues.


-- 
Mathias Koehrer
mathias_koehrer@domain.hid


Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur  44,85 €  inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2

[Xenomai-help] Re: Re: Re: A fairly small rtnet/Xenomai...

[Philippe Gerum]

On Fri, 2006-12-22 at 12:40 +0100, M. Koehrer wrote:
> Hi Philippe, 
> 
> I agree. To fix the root cause is actually the very best to do!
> This eases the life of users and developers.

Definitely, yes. The point is that once you go down the
"rt_task_system()" path, you end up being trapped into API
proliferation, which would continue with rt_task_fork, rt_task_vfork and
so on. This would a dead end, unfortunately.

Asking people to use rt_task_system() is already asking them to
understand why they should not use system() in the first place, so this
can't solve the root issue. The problem comes entirely from the fact
that we don't expect any more faults after mlockall, and COW proved us
wrong. The fact that the machine freezes is only a side-effect due to
the co-kernel constraints, the first and foremost problem is that
gracefully handling a page fault would induce uncontrolable latencies
anyway.

IOW, the problem has to be fixed at kernel level, because it's
fundamentally an arch-dependent core issue.

> 
> Regards
> 
> Mathias
> 
> > 
> > Sorry, but no, no way, I won't merge anything like this, ever. This is
> > the wrong way to go. The right way is to fix the COW issue at kernel
> > level - probably the I-pipe has to provide the required support -
> > because this is where those dirty details belong to. This is definitely
> > not an API issue, because you just cannot tell application developers to
> > care about arch-specific VM issues when using a so-called generic API
> > that has to work the same way on all archs (e.g. MMU-less platforms
> > don't care about this, others would). What could be considered as a
> > bearable limitation right now must not have any impact on long-term
> > principles, and the API stuff belongs to that category of issues.
> 
> 
-- 
Philippe.