Problem with rtems_task_variable_delete

[Fernando RUIZ CASAS]

On Wed, 10 Dec 2003 22:28:48 +0100, Dieter Schaefer wrote:

> 
> Till,
> thank's for your detailed explanation. 
> > 
> > As I already pointed out: the task variable destructor is called from a 
> > section of code which
> > is protected by 'disabling thread dispatching'. It is ILLEGAL to call 
> > 'free()' from such a section.
> > _CORE_mutex_Seize() (called indirectly by 'free()' when it acquires the 
> > allocator lock)
> > detects the violation and raises 'Internal_error_Occurred()'.
> > 
> > PR#504 introduced this safeguard. Prior to PR504 everything would "work" 
> > but the heap
> > was corrupted!
> > 
> > You must not use 'free' as a task variable dtor (or use the modified 
> > 'free()' I posted earlier
> > to work around this problem)
> > 
> > HTH
> > 
> > -- Till
> > 
> 
> For me, e.g. my programs, it's not a problem at all. If I allocate memory 
> I'll free it myself. I don't like to depend on those 'automatic' mechanism. 
> (it's a bit different in C++ of course)
> 
> I run into this problem while trying to get telnetd to work.
> telnetd uses the shell, which in turn creates a task variable and a new user 
> environment. The use of a task variable in shell is easy to modify in order to 
> avoid those problems. (btw, I already did) The other problem comes from 
> creating a private environment. shell calles rtems_libio_set_private_env(). 
> I don't want to go into that and modify it, because I don't see who/what else 
> depends on this and what the side effects could be. 

The goal for this is to have a global pointer for an user structure that 
keeps the rootfs dir, curdir, userid, groupid...
The task var keeps only a pointer for this global/local structure.
Of course a different solution was pointed by Chris Johns in order to avoid 
the use of task vars because they spend a lot of resources machine in the scheduler.

But I have designed the telnetd and the shell using only 
the rtems resources availiables.

The solution pointed by Chris is a best solution.
Placing the pointer in a task extension slot in lieu of a task var.


BRGDS.




> 
> The 'solution' proposed by PR523 is, my opinion, just a patch - not a clean 
> solution. My understanding of Realtime Systems is a bit different. 
> Why should one call free to release some malloc'ed memory in an interrupt 
> service routine? That's just a wrong design, in my opinion.
> 
> Anyway, whow/where can I get the patches associated with PR523? 
> Thru CVS? Sofar, I've only used the snapshots provided by OAR.
> 
> Regards
> Dieter Schaefer