stdout and stderr are getting mixed up?
sebastian.huber at embedded-brains.de
Thu Jun 22 06:29:55 UTC 2017
On 22/06/17 08:16, Chris Johns wrote:
> On 22/06/2017 16:08, Sebastian Huber wrote:
>> On 22/06/17 08:01, Chris Johns wrote:
>>> On 22/06/2017 15:54, Sebastian Huber wrote:
>>>> The Newlib _vfprintf_r() implementation locks the file stream, so it does ensure
>>>> this atomicity.
>>>>> We have thread-local stdio streams in Newlib.
>>> Could you please elaborate what this means?
>> Concurrent fprintf(), etc. invocations are serialized in Newlib with respect to
>> a specific FILE object.
> Is the FILE* pointer in the TLS or what the pointer points too in the TLS as well?
The FILE object itself is thread-local via Thread_Control::libc_reent
initialized via newlib_create_hook() via _REENT_INIT_PTR_ZEROED().
Maybe we could add an RTEMS-specific change to Newlib so that we still
have the thread-local stdio streams, but we initialize them to global
FILE objects by default, e.g. remove struct _reent::__sf for RTEMS. This
would also reduce the amount of per-thread storage.
>> Due to the thread-local stdio streams you have many FILE
> I have always considered stdout etc as singular. I can make as many copies of
> the pointer as I like but not the object itself.
No, see above and Newlib <sys/reent.h>.
>> You have a common output device via file descriptors 0, 1 and 2.
> Are you saying for stdout it is working but stdout and stderr in different
> threads the behavior posted can be as observed?
stdout and stderr use different FILE objects, see _REENT_INIT_PTR_ZEROED().
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 : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the users