[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
fileno(stdin) versus STDIN_FILENO and friends
- Date: Tue, 15 Mar 2011 04:35:17 -0400
- From: dufault at hda.com (Peter Dufault)
- Subject: fileno(stdin) versus STDIN_FILENO and friends
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. The behavior of a single RTEMS process should match what you'd see in a single process in a POSIX compliant system. That's why the fact that the file pointers stdin, stdout, and stderr are part of the thread context is convenient but surprising, and as long as we're offering surprising behavior I'd like to make it optionally different, i.e., optionally determine which file pointers are inherited at pthread_create() time inherited.
>> 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.
Since I'd like it to apply to all code (for example, pthread code brought in in a library) without modification I think this has to happen at the pthread attribute level and in a task creation hook called for all tasks. The interface could be a custom pthread attribute, the implementation could be a task creation hook that checked the setting and used thread specific data for the file pointers. Or something, I have to look to see how it's currently done.
HD Associates, Inc. Software and System Engineering