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
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
> > *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
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 defined
*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 back off
> 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
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
> 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
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 call
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 descriptors
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-description
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,
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.
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
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
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
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 unsubscribe
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 a
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, you'll be happy to have
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
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 run nonblock in
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
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,
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 unistd.h
#include fcntl.h
int main() {
fcntl(0, F_SETFL,
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
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 unistd.h
#include fcntl.h
int main() {
fcntl(0, F_SETFL, fcntl(0, F_GETFL, 0) | O_NONBLOCK);
return 0;
}
28 matches
Mail list logo
