stdout and stderr are getting mixed up?
Sebastian Huber
sebastian.huber at embedded-brains.de
Thu Jun 22 06:35:42 UTC 2017
On 22/06/17 08: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 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.
If we do this, then we have to be careful with fclose(), since this
would close the FILE for all threads. There is no reference counting in
the FILE objects.
--
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
mailing list