stdout and stderr are getting mixed up?
chrisj at rtems.org
Thu Jun 22 06:36:18 UTC 2017
On 22/06/2017 16:29, Sebastian Huber wrote:
> 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
>>>>> 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
> 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.
This is worth considering. I am not across the detail like you are and so I am
happy to follow your lead here.
>>> 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>.
My comment was in the context of the standard:
>>> 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().
I would expect this on any platform. When hitting the low level device I expect
some other level of locking or buffering to become the dominate factor.
More information about the users