stdout and stderr are getting mixed up?

[Sebastian Huber]

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
>> objects.
> 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.