Professional Web Applications Themes

delay on select() - UNIX Programming

> >> It is working on Solaris right now. I have not tried it on Linux yet [/ref][/ref] can [/ref] >  > > > If execution is blocked inside malloc(), that sounds like someone is > calling malloc() from a signal handler. >[/ref] No. It is not. Shuqing...

  1. #21

    Default Re: delay on select()

    > >> It is working on Solaris right now. I have not tried it on Linux yet [/ref][/ref]
    can [/ref]

    >
    >
    > If execution is blocked inside malloc(), that sounds like someone is
    > calling malloc() from a signal handler.
    >[/ref]

    No. It is not.

    Shuqing


    Shuqing Guest

  2. #22

    Default Re: delay on select()

    On 2003-12-31, David Schwartz <com> wrote: 
    [...] 
    >
    > No, that's not true. I'm suspecting you don't understand how Nagle
    > works.[/ref]

    Could be. From reading different specs I have the impression that this
    algorithm attempts to avoid sending multiple small datagrams by holding
    up the first one in hope that there'll be some more data to come. So if
    in my program I say 'send(s, buf, 10, 0)' then this data shall be held
    up for a short while, just in case if I do another 'send'. Please
    correct me if I'm wrong.

    Andrei
    Andrei Guest

  3. #23

    Default Re: delay on select()

    On Thu, 01 Jan 2004 11:11:48 -0500, Shuqing Wu wrote: 
    >>
    >> You really should not do any memory allocation within the inner loop of
    >> your networking code. The standard library malloc and free are
    >> protected by locks besides being somewhat inefficent object management
    >> routines to start with. Allocate your memory in advance and reuse it as
    >> much as possible.
    >>[/ref]
    > It happens when it try to allocate memory for a new transaction context.
    > By the way, it works fine on Solaris, but not on Linux. Do you suggested
    > that Linux is not allow the application allocate memory dynamically? Or
    > maybe some network application? In my case, I am working on a
    > tion PostgreSQL projest. Is there anything I should take a look
    > inside, in specific?[/ref]

    My advice was meant to be general. Blocking within malloc is not a known
    phenomenon on any system and should not happen in a compliant environment.

    Are you executing your code within the runtime of PostgreSQL? Is
    this a PostgreSQL module of some kind. If so, I would be suspicous of
    constrains surrounding that environment. How does PostgreSQL multiplex
    transactions? Perhaps you should query the PostgreSQL mailing list.

    If all else fails you could also try a lockless memory allocator. C++
    STL has one. I am about to release one for libmba (but I've been "about
    to release" it for a month) which is very simple plain ANSI C. I seriously
    doubt that could block on you.

    Mike
    Michael Guest

  4. #24

    Default Re: delay on select()

    On 2003-12-31, Michael B Allen <com> wrote: 
    >
    > If you prefer to write to sockets directly that is a matter of taste
    > but it is not more efficient. Regardless of protocol you are using an[/ref]
    [...]

    :) I know. I bet still there are some places where this approach is more
    efficient, since there's TCP_CORK on Linux :)
     
    >>
    >> Won't help me? In SMPP protocol each PDU is not more than 300 bytes long
    >> and the next one won't come untill the response to the first one
    >> arrived. So small datagrams are inevitable in this case. That is why I
    >> have to turn Nagle off using TCP_NODELAY. And it does help me. :)[/ref]
    >
    > I think you guys are talking about different issues. The purpose of
    > Nagle's algorithm is not to coalesce fragments of a PDU. It's to coalesce
    > multiple whole PDUs. TCP_CORK is used to coalesce fragements of a PDU
    > (albeit somewhat of a hack).[/ref]

    Sorry if it was confusing. In this particular case I was talking only
    about TCP_NODELAY. And only about the case when there are not PDU to be
    coalesced. I guess all I wanted to say was: "If I know that Nagle is not
    needed then I can turn it off".

    Correction, indeed I had a misunderstanding about implementation of
    Nagle. In the case that I've described (SMPP) it does not come into
    play. But it comes into play for OP. Because there he has large chunk to
    send and after sending first piece Nagle delays sending of the second
    untill acknowledgment for the first one comes. That is why turning off
    of Nagle is good for OP.

    Andrei
    Andrei Guest

  5. #25

    Default Re: delay on select()

    Andrei Voropaev <ru> writes:
     

    Nagle only delays sending data is there's previously send unack'ed
    data and we're sending less than a full segment.

    (So it's the combination of delayed acks and sending less then segment
    sized packets which is the killer)

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.
    Casper Guest

  6. #26

    Default Re: delay on select()


    "Andrei Voropaev" <ru> wrote in message
    news:bt3bbm$2pj7v$news.uni-berlin.de... 

     [/ref]
     


    That couldn't possibly be right. If that were true, no buffering
    strategy would help you when you only needed to send a few bytes of data.

    DS




    David Guest

  7. #27

    Default Re: delay on select()



    Andrei Voropaev wrote: 
    >
    > [...]

    >>
    >> No, that's not true. I'm suspecting you don't understand how Nagle
    >>works.[/ref]
    >
    >
    > Could be. From reading different specs I have the impression that this
    > algorithm attempts to avoid sending multiple small datagrams by holding
    > up the first one in hope that there'll be some more data to come. So if
    > in my program I say 'send(s, buf, 10, 0)' then this data shall be held
    > up for a short while, just in case if I do another 'send'. Please
    > correct me if I'm wrong.
    >
    > Andrei[/ref]

    I would have to say that you are wrong. What you are describing is more
    like the delayed acknowledgment algorithm, but not quite.

    The Nagle algorithm does not delay data in the hope that there will be more
    data to send later, although it does accomplish this and that feature is
    part of the motivation.

    However, its primary aim is to limit the inefficiency of a data stream to
    provide congestion avoidance. Because of the overhead associated with
    each ethernet packet, the smaller the payload, the less efficient the data
    connection, and the more likely a data stream will contribute to congestion.
    It is essentially penalizing you for using the network inefficiently so that
    more data streams can be handled simultaneously. Viewed in this way, it can
    be seen that using TCP_NODELAY without thought is plain anti-social. If you
    need better response than Nagle allows, you really better have a good reason
    for overriding Nagle, other than "I need better throughput". You should
    really recode to handle the buffering better. Or if the buffering is as good
    as it can be, think about a protocol change. Running into problems with
    Nagle is a signal that you should rethink your methodology, not a signal
    to use TCP_NODELAY.

    --
    blu

    Lesson from the blackout of 2003:
    The power grid is THE most critical infrastructure, upon which all
    others depend, and nobody really knows how it works.
    --------------------------------------------------------------------------------
    Brian Utterback - Solaris Sustaining (NFS/Naming) - Sun Microsystems Inc.,
    Ph/VM: 781-442-1343, Em:brian.utterback-at-ess-you-enn-dot-kom

    Brian Guest

Page 2 of 2 FirstFirst 12

Similar Threads

  1. Select a list of items into an aliased field when doinga select
    By ehaemmerle in forum Coldfusion Database Access
    Replies: 3
    Last Post: March 18th, 10:49 PM
  2. Replies: 0
    Last Post: September 24th, 03:24 AM
  3. Replies: 0
    Last Post: September 11th, 11:26 AM
  4. Replies: 0
    Last Post: September 11th, 12:19 AM
  5. Replies: 0
    Last Post: April 15th, 01:22 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139