[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
fileno(stdin) versus STDIN_FILENO and friends
- Date: Tue, 15 Mar 2011 11:46:53 +1100
- From: chrisj at rtems.org (Chris Johns)
- Subject: fileno(stdin) versus STDIN_FILENO and friends
On 15/03/11 10:10 AM, Peter Dufault wrote:
> On Mar 14, 2011, at 6:56 , Chris Johns wrote:
>> I think it is reasonable to make this change. The whole shell and telnet
>> on RTEMS is an application trick to make the RTEMS "process" appear
>> multi-user and process based. We should attempt to make this emulation
>> appear as standard.
> 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
> If we're operating outside of any definition
I think we are because you are using part of some application type code
that is the shell and telnet and here we would like the process
standards to apply if they make sense and it can be done.
> then I suggest RTEMS make the stdio thread inheritance behavior optional: I'd prefer an inherited stdin,stdout,stderr, and I'll look at what it takes to make it work in the newlib framework. Others might like the way it works now, where all threads revert to file descriptors 0, 1, and 2 for stdin, stdout, and stderr for newly created threads.
I agree for the shell and telnet type code and here I would make the
behaviour you want as the default.
For me the general thread create case will have wait and be based on
what you discover.