This is the mail archive of the mailing list for the newlib 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: How to destroy _reent structure

On 24/04/13 20:51, Joel Sherrill wrote:
On 4/24/2013 12:54 PM, Sebastian Huber wrote:
On 24/04/13 13:10, Sebastian Huber wrote:
Hello Corinna,

On 04/24/2013 12:26 PM, Corinna Vinschen wrote:
On Apr 24 10:04, Sebastian Huber wrote:

there is _REENT_INIT_PTR() for initialization, but how can I destroy
a _reent structure.  Is this _wrapup_reent()?
Try _reclaim_reent.  But it's not the same as _REENT_INIT_PTR since
_REENT_INIT_PTR does not allocate any memory.


so for initialization we can use:

struct _reent *p = malloc(sizeof(*p));
if (p != NULL) {

For destruction we can use:

If I use this sequence in RTEMS, then I have the following problem.
RTEMS opens (via open()) the file descriptors 0, 1 and 2 during system
initialization.  In RTEMS the file descriptors are a global resource.  A
thread will do the initialization steps above during creation time.  Now
suppose a thread calls fopen().  This will check that _REENT is
initialized.  This will execute the following code for stdin, stdout and
stderr FILE streams (newlib/libc/stdio/findfp.c):

static _VOID
_DEFUN(std, (ptr, flags, file, data),
              FILE *ptr _AND
              int flags _AND
              int file  _AND
              struct _reent *data)
    ptr->_file = file;
    ptr->_close = __sclose;

It simply assumes that file descriptors 0, 1 and 2 are available and
registers the __sclose() function (which will call close()). During
_reclaim_reent() the stdin, stdout and stderr FILE streams are closed.
Since we have no open() call for these file descriptors this will close
the global file descriptors 0, 1 and 2.  I think at least for RTEMS we
should set ptr->_close to NULL.
This goes back to the issue of whether the FILE * are per thread
or per process. I know we have discussed this before and not resolved

As best I can tell from POSIX, open() integer descriptors are process
wide. There is a set for the process.

But I can't find a clear indication for "FILE *" from fopen().
If they are per-process, then why are_stdin, _stdout, _stderr,
and _sf in the reent structure?

Should I be able to fopen() a file in one thread, exit that thread,
and then be able to use the FILE * pointer in another thread?

I am trying to back off and make sure I understand the C99
and POSIX requirements.

I think this per-thread stdin, stdout and stderr is a feature of Newlib. I wouldn't change it, but we have to fix the thread creation and destruction issues in RTEMS related to that. I will provide patches in the next couple of days.

Streams opened with fopen() are part of _GLOBAL_REENT and not associated with a particular thread. The stdin, stdout and stderr are a bit different, since you don't have to open them, they simply exist.

What is the purpose of _wrapup_reent()? Its not called from within
Newlib and I don't find a function that can register an atexit handler
in a non-global _reent structure.  There is also no public header file
for this function.
I think we should move the _wrapup_reent() into a separate file.
I suspect _wrapup_reent() is dead. But moving it is probably a safe
alternative to killing it.

I wondered a bit about cleanup_glue().

+ cleanup_glue() is not referenced outside reent.c. Should it be static?
+ cleanup_glue() is recursive. Is this desirable? Can its use in
    _reclaim_reent() be replaced with a loop?


Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  :
PGP     : Public key available on request.

Diese Nachricht ist keine geschÃftliche Mitteilung im Sinne des EHUG.

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