O_NONBLOCK supposedly hits the entire 'ofile' and not just the fd:
http://cr.yp.to/unix/nonblock.html
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
-
To unsubscribe from this list: send the line "unsubs
> > *Every* blocking fd operation should be followed by a check to
> > see if the
> > operation failed, succeeded, or partially succeeded. If it partially
> > succeeded, it needs to be continued. If it failed, you need to
> > check if the
> > error is fatal or transient. If transient, you need to
David Schwartz wrote:
[]
>> Currently changing O_NONBLOCK on stdin/out/err affects other,
>> possibly unrelated processes - they don't expect that *their*
>> reads/writes will start returning EAGAIN!
>
> Then they're broken. Sorry, that's just the way it is. Code should always
> correctly handle d
> Easy. O_NONBLOCK should only affect whether read/write blocks or
> returns EAGAIN. It's logical for this setting to be per-process.
Sadly, that's not what POSIX says. POSIX says that 'dup' and 'fork' create
two references to the same file description and that O_NONBLOCK is a
per-file-descriptio
On Sunday 04 February 2007 01:55, David Schwartz wrote:
>
> > That's a bug, right? I couldn't find anything to that effect in IEEE
> > Std. 1003.1, 2004 Edition...
> >
> > Ciao,
> > Roland
>
> It's not a bug, there's no rational alternative. What would two indepedent
> file d
> That's a bug, right? I couldn't find anything to that effect in IEEE
> Std. 1003.1, 2004 Edition...
>
> Ciao,
> Roland
It's not a bug, there's no rational alternative. What would two indepedent
file descriptors for the same end of a TCP connection be? What happens when
you
Roland Kuhn <[EMAIL PROTECTED]> writes:
> Hi Guillaume!
>
> On 2 Feb 2007, at 14:48, Guillaume Chazarain wrote:
>
> > 2007/2/2, Roland Kuhn <[EMAIL PROTECTED]>:
> >
> >> That's a bug, right?
> >
> > No, if you want something like: (echo toto; date; echo titi) > file
> > to work in your shell, yo
Hi Guillaume!
On 2 Feb 2007, at 14:48, Guillaume Chazarain wrote:
2007/2/2, Roland Kuhn <[EMAIL PROTECTED]>:
That's a bug, right?
No, if you want something like: (echo toto; date; echo titi) > file
to work in your shell, you'll be happy to have the seek position
shared in the processes.
As
2007/2/2, Roland Kuhn <[EMAIL PROTECTED]>:
That's a bug, right?
No, if you want something like: (echo toto; date; echo titi) > file
to work in your shell, you'll be happy to have the seek position
shared in the processes.
--
Guillaume
-
To unsubscribe from this list: send the line "unsubscrib
Hi Philippe!
On 2 Feb 2007, at 00:15, Philippe Troin wrote:
Denis Vlasenko <[EMAIL PROTECTED]> writes:
What share the same file descriptor? MC and programs started from it?
All the processes started from your shell share at least fds 0, 1
and 2.
I thought after exec() fds atre either c
Denis Vlasenko <[EMAIL PROTECTED]> writes:
> What share the same file descriptor? MC and programs started from it?
All the processes started from your shell share at least fds 0, 1 and 2.
> I thought after exec() fds atre either closed (if CLOEXEC) or
> becoming independent from parent process
On Tuesday 30 January 2007 04:40, Philippe Troin wrote:
> > int main() {
> > fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) | O_NONBLOCK);
> > return 0;
> > }
> >
> > int main() {
> > fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) & ~O_NONBLOCK);
> > return 0;
> > }
> >
> > If I r
Denis Vlasenko <[EMAIL PROTECTED]> writes:
> Hi,
>
> I am currently on Linux 2.6.18, x86_64.
> I came across strange behavior while working on one
> of busybox applets. I narrowed it down to these two
> trivial testcases:
>
> #include
> #include
> int main() {
> fcntl(0, F_SETFL, fcntl
Hi,
I am currently on Linux 2.6.18, x86_64.
I came across strange behavior while working on one
of busybox applets. I narrowed it down to these two
trivial testcases:
#include
#include
int main() {
fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) | O_NONBLOCK);
return 0;
}
#include
#inc
14 matches
Mail list logo
