Nonblocking socket - HP UX

This is a discussion on Nonblocking socket - HP UX ; Hi, Following the documentation on hp-ux I set my socket as non-blocking: int nFlags; nFlags = fcntl(ListenSocket, F_GETFL, 0); nFlags |= O_NONBLOCK; if (fcntl(ListenSocket, F_SETFL, nFlags) == -1) return false; This actually to work fine but what I don't understand ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Nonblocking socket

  1. Nonblocking socket

    Hi,

    Following the documentation on hp-ux I set my socket as non-blocking:

    int nFlags;

    nFlags = fcntl(ListenSocket, F_GETFL, 0);

    nFlags |= O_NONBLOCK;

    if (fcntl(ListenSocket, F_SETFL, nFlags) == -1)

    return false;



    This actually to work fine but what I don't understand is that accept()
    returns errno 2 (ENOENT) instead of EAGAIN or EWOULDBLOCK like the
    documentation says.

    Can anyone shed some light on this?

    The error code that I get is not even mentioned in the manpage for accept.

    Thanks in advance.

    -- Henrik



  2. Re: Nonblocking socket

    Henrik Goldman wrote:
    > Hi,
    >
    > Following the documentation on hp-ux I set my socket as non-blocking:
    >
    > int nFlags;
    >
    > nFlags = fcntl(ListenSocket, F_GETFL, 0);
    >
    > nFlags |= O_NONBLOCK;
    >
    > if (fcntl(ListenSocket, F_SETFL, nFlags) == -1)
    >
    > return false;
    >
    >
    >
    > This actually to work fine but what I don't understand is that accept()
    > returns errno 2 (ENOENT) instead of EAGAIN or EWOULDBLOCK like the
    > documentation says.
    >
    > Can anyone shed some light on this?
    >
    > The error code that I get is not even mentioned in the manpage for accept.


    Which protocol family ? Socket is just a entry point for
    several protocol families, so a bug in the accept entry
    routine of the specific PF could cause the system call
    accept() to return an unexpected error.

    Following is just my guess - if you are using PF which
    does not support NONBLOCKing sockets, then it might
    return ENOENT (which in practice should return ENOTSUP).
    Does the accept work okay with a blocking socket ?

    --vishwas

  3. Re: Nonblocking socket

    >
    > Which protocol family ? Socket is just a entry point for
    > several protocol families, so a bug in the accept entry
    > routine of the specific PF could cause the system call
    > accept() to return an unexpected error.


    Actually I'm using AF:

    sin.sin_addr.s_addr = INADDR_ANY;

    sin.sin_family = AF_INET;

    sin.sin_port = htons(nPort);



    > Following is just my guess - if you are using PF which
    > does not support NONBLOCKing sockets, then it might
    > return ENOENT (which in practice should return ENOTSUP).


    > Does the accept work okay with a blocking socket ?


    The weird thing is that everything seems to work fine except the fact that
    accept returns a undocumented error code. I could just filter for that error
    since it's trivial to do so but I don't like when it's undocumented.
    The socket gets accepted once a client connects and everything works as
    suppose to.
    The manpage says that it should return:

    [EAGAIN] Nonblocking I/O is enabled using O_NONBLOCK and no
    connections are present to be accepted.

    Before I used FIONBIO flag with ioctl since it seems to work on almost all
    other unix then hp-ux but since the socket was still blocking I changed it
    to this flag instead.
    It's very weird but it doesn't give me a good feeling why it returns this
    error code.

    Is there anything else I could try?

    -- Henrik



  4. Re: Nonblocking socket

    Henrik Goldman wrote:

    > Actually I'm using AF:
    > sin.sin_addr.s_addr = INADDR_ANY;
    > sin.sin_family = AF_INET;
    > sin.sin_port = htons(nPort);


    How about the socket() call itself?

    >> Does the accept work okay with a blocking socket ?


    Yes. It should.

    > The weird thing is that everything seems to work fine except the
    > fact that accept returns a undocumented error code.


    It wouldn't be the first time, and alas, probably not the last.

    > I could just filter for that error since it's trivial to do so but I
    > don't like when it's undocumented. The socket gets accepted once a
    > client connects and everything works as suppose to.


    > The manpage says that it should return:


    > [EAGAIN] Nonblocking I/O is enabled using O_NONBLOCK and no
    > connections are present to be accepted.


    > Before I used FIONBIO flag with ioctl since it seems to work on
    > almost all other unix then hp-ux but since the socket was still
    > blocking I changed it to this flag instead. It's very weird but it
    > doesn't give me a good feeling why it returns this error code.


    > Is there anything else I could try?


    There is always the usual song and dance about being up on the latest
    Transport/sockets patch(es) for the OS you are running.

    rick jones
    --
    Process shall set you free from the need for rational thought.
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  5. Re: Nonblocking socket

    > How about the socket() call itself?

    It looks like:
    ListenSocket = socket(AF_INET, SOCK_STREAM, 0);

    I would say that it looks pretty standard.
    >
    > There is always the usual song and dance about being up on the latest
    > Transport/sockets patch(es) for the OS you are running.


    Are you saying that because I am on the latest version I should expect
    problems? I'm using the latest 11.23 so I would expect that the buglevel is
    low.. or perhaps I'm missing some specific patches?

    What about the code that I posted initially with setting the non-blocking
    flag? Is that correctly performed? I did this code after what I found on the
    net and following the documentation. However the documentation is so poor
    that I am not sure I understood it correctly. The man pages are not very
    clear on the usage.

    -- Henrik



  6. Re: Nonblocking socket

    Henrik Goldman wrote:
    >> How about the socket() call itself?


    > It looks like:
    > ListenSocket = socket(AF_INET, SOCK_STREAM, 0);


    > I would say that it looks pretty standard.


    I agree.

    >>
    >> There is always the usual song and dance about being up on the latest
    >> Transport/sockets patch(es) for the OS you are running.


    > Are you saying that because I am on the latest version I should
    > expect problems? I'm using the latest 11.23 so I would expect that
    > the buglevel is low.. or perhaps I'm missing some specific patches?


    I'm suggesting you make sure you have the latest patches installed.
    Perhaps even going so far as to install TOUR 3.1 (although IIRC that
    means sticking with later TOURs rather than the "normal" patch stream).

    > What about the code that I posted initially with setting the
    > non-blocking flag? Is that correctly performed? I did this code
    > after what I found on the net and following the
    > documentation. However the documentation is so poor that I am not
    > sure I understood it correctly. The man pages are not very clear on
    > the usage.


    I'd have suggested that maybe it was a bogus FD being passed, but you
    said that the code seems to otherwise work. It could simply be an
    omission in the manpage, or it could be a bug in the accept() path
    somewhere.

    For the "definitive" answer it would be best to log a call with the
    Response Centre.

    rick jones
    --
    The glass is neither half-empty nor half-full. The glass has a leak.
    The real question is "Can it be patched?"
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  7. Re: Nonblocking socket

    Henrik Goldman wrote:
    > Before I used FIONBIO flag with ioctl since it seems to work on
    > almost all other unix then hp-ux but since the socket was still
    > blocking I changed it to this flag instead.


    Can you expand on that a bit? Were you checking the ListenSock or the
    socket returned from the accept() call?

    rick jones
    --
    The computing industry isn't as much a game of "Follow The Leader" as
    it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
    - Rick Jones
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  8. Re: Nonblocking socket

    >> Before I used FIONBIO flag with ioctl since it seems to work on
    >> almost all other unix then hp-ux but since the socket was still
    >> blocking I changed it to this flag instead.

    >
    > Can you expand on that a bit? Were you checking the ListenSock or the
    > socket returned from the accept() call?


    The idea is that I have a accept thread which blocks on accept when waiting
    for new connections. On all other unix platforms that my software works on
    (aix, mac osx, solaris etc.) I used FIONBIO flag to make the socket
    non-blocking. The hp-ux man page for accept says that this is a bad idea.
    When I left the code as it was for the other platforms it acted like the
    socket was still blocking. In other words even though the flag is set the
    socket is still blocking and the non-blocking flag has no effect.
    So I had to change it to the O_NONBLOCK flag which then again has made
    accept() function act weird.

    -- Henrik



  9. Re: Nonblocking socket

    Henrik Goldman wrote:
    > The idea is that I have a accept thread which blocks on accept when
    > waiting for new connections. On all other unix platforms that my
    > software works on (aix, mac osx, solaris etc.) I used FIONBIO flag
    > to make the socket non-blocking.


    OK, I'm being dense, but if you have an accepting thread blocking on
    accept() why are you trying to mark the listen socket non-blocking?

    > The hp-ux man page for accept says that this is a bad idea.


    Do you mean this section?

    If no pending connections are present on the queue and
    nonblocking mode has not been enabled with the fcntl()
    O_NONBLOCK or O_NDELAY flags or the ioctl() FIOSNBIO request,
    accept() blocks the caller until a connection is present.
    O_NONBLOCK and O_NDELAY are defined in (see
    fcntl(2), fcntl(5), and socket(7)). FIOSNBIO and the equivalent
    request FIONBIO are defined in , although use of
    FIONBIO is not recommended (see ioctl(2), ioctl(5), and
    socket(7)).

    My read of that, along with the section 5 manpage for ioctl is that it
    is suggested that one use FIOSNBIO rather than FIONBIO. Not that the
    ioctl mechanism itself is not suggested.

    rick jones
    --
    No need to believe in either side, or any side. There is no cause.
    There's only yourself. The belief is in your own precision. - Jobert
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  10. Re: Nonblocking socket

    > Do you mean this section?
    >
    > If no pending connections are present on the queue and
    > nonblocking mode has not been enabled with the fcntl()
    > O_NONBLOCK or O_NDELAY flags or the ioctl() FIOSNBIO request,
    > accept() blocks the caller until a connection is present.
    > O_NONBLOCK and O_NDELAY are defined in (see
    > fcntl(2), fcntl(5), and socket(7)). FIOSNBIO and the equivalent
    > request FIONBIO are defined in , although use of
    > FIONBIO is not recommended (see ioctl(2), ioctl(5), and
    > socket(7)).
    >
    > My read of that, along with the section 5 manpage for ioctl is that it
    > is suggested that one use FIOSNBIO rather than FIONBIO. Not that the
    > ioctl mechanism itself is not suggested.
    >


    Yes, I had problems with both of them so that was not very encouraging.

    The reason why I have non-blocking accept is that it allows the system to
    shutdown cleanly when all threads are being asked to shutdown. This is the
    reason why I want to do as I do.

    So is the suggestion for now just to filter on the undocuemented error and
    then hope that no more undocumented stuff comes up?

    -- Henrik



  11. Re: Nonblocking socket

    Henrik Goldman wrote:
    > So is the suggestion for now just to filter on the undocuemented
    > error and then hope that no more undocumented stuff comes up?


    Unofficially? Yes.

    Officially, contact the RC

    rick jones
    --
    The glass is neither half-empty nor half-full. The glass has a leak.
    The real question is "Can it be patched?"
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

+ Reply to Thread