fileno(stdin) versus STDIN_FILENO and friends

[Till Straumann]

On 03/15/2011 09:59 AM, Gedare Bloom wrote:
> I think there is an interesting philosophical debate here. Telnet and
> shell are logically separate from an application, but RTEMS is only
> designed to provide a single 'process'. So according to the principle
> of least surprise, anything that is per-process should be shared by
> all threads. Ralf pointed to a source that says these FILE*
> 'constants' should be per-process, so it is reasonable for a user to
> expect them to be shared by all threads.  Since telnet and shell are
> emulating separate processes, however, the abstraction (and RTEMS'
> threading model) breaks.
>
> Since treating telnet/shell as separate processes is arguably a good
> thing, support for process-like constructs seems useful. However, the
> default behavior should be to treat all threads as part of a single
> (logical) process unless otherwise managed, which means the per-thread
> FILE* is wrong.

I like your assessment. I believe the newlib semantics also influence
this discussion. IIRC they are as follows:

In general, FILE objects are 'global', i.e., a FILE opened by one
thread doesn't go away when the thread is deleted. However,
unless the patches provided with bugzilla #1247 etc. are applied
there are race conditions when multiple threads access the same FILE
(or try to fopen() different files concurrently).
(Sidenote: other newlib objects are also unprotected unless 1247 is
fixed).

HOWEVER: stdin/stdout/stderr are treated differently by newlib.
These three FILEs are 'per-thread' entities and are destroyed
(albeit this currently may still leak memory, see PR #1246)
when a thread is deleted.

Note that the stdin/stdout/stderr FILEs are 'lazy-initialized'
upon first use, i.e., a thread which doesn't use them doesn't
create them.

-> stdin/stdout/stderr refer to different streams/buffers
    for each thread (but read/write the same underlying file
    descriptors) and the buffers are 'attached' to the
    thread's 'reent' struct.
-> other FILEs are global and attached to the global 'reent'
    struct.


-- Till



>
> On Tue, Mar 15, 2011 at 4:51 AM, Ralf Corsepius
> <ralf.corsepius at rtems.org>  wrote:
>> On 03/15/2011 09:35 AM, Peter Dufault wrote:
>>>
>>> On Mar 14, 2011, at 8:46 , Chris Johns wrote:
>>>
>>>>> I think (but don't know, but would like to know) that we're talking
>>>>> about behavior that isn't defined by a standard. If the behavior is defined,
>>>>> then RTEMS should ensure things follow the standard, but I haven't located a
>>>>> definition yet.
>>>>
>>>> I do not know of a standard for managing these things inside a process
>>>> environment. The standards talk about processes and this is what we are
>>>> attempting to emulate with the shell and telnet. This is what I was
>>>> referring to.
>>>
>>> In my opinion an RTEMS collection of POSIX threads is a single process.
>>
>> This is right. RTEMS is a single process.
>>
>> Ralf
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users