Home > Archive > Unix Programming > August 2007 > Attempting to set file descriptors to non blocking: tests fail
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Attempting to set file descriptors to non blocking: tests fail
|
|
| Michael 2007-08-19, 7:09 pm |
| I have 3 functions, as follows (sans fluff such as error handling, et
al)
is_blocking(int s)
{
int flags = ::fcntl(s, F_GETFL, 0);
if( flags == (flags | O_NONBLOCK) )
return false;
return true;
}
set_nonblocking(int s)
{
int flags = ::fcntl(s, F_GETFL, 0);
::fcntl(s, F_SETFL, flags | O_NONBLOCK);
}
set_blocking(int s)
{
int flags = ::fcntl(s, F_GETFL, 0);
::fcntl(s, F_SETFL, flags & (~O_NONBLOCK));
}
I have a test that does basically the following:
set_blocking(s);
if( !is_blocking(s))
fail();
and it's failing. Any hints?
| |
|
|
>
> set_blocking(s);
> if( !is_blocking(s))
> fail();
>
>
>
> and it's failing. Any hints?
Check the return value from the fcntl systemcalls.
they could be -1 ...
HTH,
AvK
| |
| SM Ryan 2007-08-19, 7:09 pm |
| Michael <Michael.Reiland@gmail.com> wrote:
# I have 3 functions, as follows (sans fluff such as error handling, et
# al)
#
#
# is_blocking(int s)
# {
# int flags = ::fcntl(s, F_GETFL, 0);
# if( flags == (flags | O_NONBLOCK) )
return !(flags & O_NONBLOCK)
# }
#
# set_nonblocking(int s)
# {
# int flags = ::fcntl(s, F_GETFL, 0);
# ::fcntl(s, F_SETFL, flags | O_NONBLOCK);
# }
#
# set_blocking(int s)
# {
# int flags = ::fcntl(s, F_GETFL, 0);
# ::fcntl(s, F_SETFL, flags & (~O_NONBLOCK));
# }
#
#
# I have a test that does basically the following:
#
# set_blocking(s);
# if( !is_blocking(s))
# fail();
#
#
#
# and it's failing. Any hints?
#
#
#
--
SM Ryan http://www.rawbw.com/~wyrmwif/
I hope it feels so good to be right. There's nothing more
exhilarating pointing out the shortcomings of others, is there?
| |
|
| On Sun, 19 Aug 2007 22:43:38 +0000, SM Ryan wrote:
> Michael <Michael.Reiland@gmail.com> wrote:
> # I have 3 functions, as follows (sans fluff such as error handling, et
> # al)
> #
> #
> # is_blocking(int s)
> # {
> # int flags = ::fcntl(s, F_GETFL, 0);
> # if( flags == (flags | O_NONBLOCK) )
>
>
Yes, that looked pretty unreadable.
I would even prefer(since I don't trust C++/True/false):
return (flags & O_NONBLOCK) ? False : True;
(I would probably prefer the function name "is_nonblocking()" )
BTW function names that start with "is" are reserved in C. Don't know
about C++.
AvK
| |
| Ben Bacarisse 2007-08-19, 10:12 pm |
| moi <root@localhost.localdomain> writes:
> On Sun, 19 Aug 2007 22:43:38 +0000, SM Ryan wrote:
>
>
> Yes, that looked pretty unreadable.
> I would even prefer(since I don't trust C++/True/false):
> return (flags & O_NONBLOCK) ? False : True;
>
> (I would probably prefer the function name "is_nonblocking()" )
> BTW function names that start with "is" are reserved in C. Don't know
> about C++.
In C, only identifiers starting "is" and followed by a lowercase
letter are reserved. is_xxx is fine, as is isXXX.
--
Ben.
| |
| Michael 2007-08-19, 10:12 pm |
| On Aug 19, 11:20 pm, moi <r...@localhost.localdomain> wrote:
> On Sun, 19 Aug 2007 22:43:38 +0000, SM Ryan wrote:
>
> Yes, that looked pretty unreadable.
> I would even prefer(since I don't trust C++/True/false):
> return (flags & O_NONBLOCK) ? False : True;
>
> (I would probably prefer the function name "is_nonblocking()" )
> BTW function names that start with "is" are reserved in C. Don't know
> about C++.
>
> AvK
mol:
* I stated in my original posting that the code did not include error
handling.
* In the event that my test in is_blocking would produce an incorrect
result, I would appreciate the feedback. However, from your reply I'm
going to make 2 separate guesses. 1. It's functionally correct and 2.
you managed to read it.
* I'm working in C++ and this is sitting in a namespace. The use of
the scope resolution operator makes it apparent that it's C++ code. I
never mentioned any namespace, so I can almost forgive you that,
except for the fact that I never mentioned it because it has
absolutely nothing to do with the problem.
If you'd like to discuss the stylistic advantages/di vantages to the
approaches that I've taken, please start another line of discussion.
SM Ryan:
That was how I had originally codified it, but I changed it to the
explicit true/false return in an attempt to illuminate all the
corners. It was basically a last ditch effort to make sure some weird
craziness wasn't going on.
| |
| SM Ryan 2007-08-19, 10:12 pm |
| moi <root@localhost.localdomain> wrote:
# On Sun, 19 Aug 2007 22:43:38 +0000, SM Ryan wrote:
#
# > Michael <Michael.Reiland@gmail.com> wrote:
# > # I have 3 functions, as follows (sans fluff such as error handling, et
# > # al)
# > #
# > #
# > # is_blocking(int s)
# > # {
# > # int flags = ::fcntl(s, F_GETFL, 0);
# > # if( flags == (flags | O_NONBLOCK) )
# >
# >
#
# Yes, that looked pretty unreadable.
# I would even prefer(since I don't trust C++/True/false):
# return (flags & O_NONBLOCK) ? False : True;
Assuming False and True are defined the way they should be,
!p ? False : True
is equivalent to
!p
Whether the more verbose is easier for you to understand, there's
no difference in the values.
# (I would probably prefer the function name "is_nonblocking()" )
That could be !!(flags & O_NONBLOCK).
--
SM Ryan http://www.rawbw.com/~wyrmwif/
So basically, you just trace.
| |
|
| On Sun, 19 Aug 2007 17:30:28 -0700, Michael wrote:
> On Aug 19, 11:20 pm, moi <r...@localhost.localdomain> wrote:
[color=darkred]
> mol:
>
> * I stated in my original posting that the code did not include error
> handling.
My bad. Sorry about that.
>
> * In the event that my test in is_blocking would produce an incorrect
> result, I would appreciate the feedback. However, from your reply I'm
> going to make 2 separate guesses. 1. It's functionally correct and 2.
> you managed to read it.
And 3. Since it is functionally correct, it can be tested separately (and
probably work as you expect it to. Ergo 4. You probably snipped too much ? )
>
> * I'm working in C++ and this is sitting in a namespace. The use of the
> scope resolution operator makes it apparent that it's C++ code. I never
> mentioned any namespace, so I can almost forgive you that, except for
> the fact that I never mentioned it because it has absolutely nothing to
> do with the problem.
Yes. Does errno sit in a global-scope namespace, too ?
>
>
> If you'd like to discuss the stylistic advantages/divantages to the
> approaches that I've taken, please start another line of discussion.
>
This is usenet, remember ?
> SM Ryan:
>
> That was how I had originally codified it, but I changed it to the
> explicit true/false return in an attempt to illuminate all the corners.
> It was basically a last ditch effort to make sure some weird craziness
> wasn't going on.
That is what most people would do, I suppose.
AvK
| |
| Michael 2007-08-20, 8:22 am |
| On Aug 20, 7:41 am, moi <r...@localhost.localdomain> wrote:
> On Sun, 19 Aug 2007 17:30:28 -0700, Michael wrote:
>
>
> My bad. Sorry about that.
>
>
>
>
> And 3. Since it is functionally correct, it can be tested separately (and
> probably work as you expect it to. Ergo 4. You probably snipped too much ? )
is_blocking is passing it's tests. You were the one who chose to
worry about that particular function, not I.
I'm not that experienced with unix style file descriptors, hence my
mailing of this group. Am I doing something with my calls to fcntl
that would cause it to not block? Under what circumstances will fcntl
not change a descriptor to a blocking status? (in reference to both a
file descriptor and a socket descriptor).
The calls to fcntl are *not* giving errors.
>
>
>
>
> Yes. Does errno sit in a global-scope namespace, too ?
We both know the answer to that, what is it you're trying to lead to?
>
>
>
>
> This is usenet, remember ?
>
>
>
> That is what most people would do, I suppose.
>
> AvK
| |
| Michael 2007-08-20, 8:22 am |
| I found the problem. I had gotten my bit manipulations backwards,
unsetting the O_NONBLOCK flag instead of setting it. The example code
I gave previously was what I thought I did, but apparently it wasn't
what I actually did.
Thanks for the help guys, hopefully I won't discover any more silly
errors.
|
|
|
|
|