[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

fileno(stdin) versus STDIN_FILENO and friends



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.

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
>