Re: Much improved sosend_*() functions




On Fri, 29 Sep 2006, Andre Oppermann wrote:

The patch is available here: http://people.freebsd.org/~andre/sosend+m_uiotombuf-20060928.diff

I like the concept of these changes in principle -- this is the reason I broke out sosend_copyin(), so that we could start plugging bits of the send routines more easily for optimization. However, I think we need to review this really carefully. A casual glance brought up one question, and I hope to get a chance to review this in detail in the next few days. The question is with regard to the 'space' variable. When breaking out sosend_copyin(), I originally simply passed space in as an argument, which is what you do currently. However, I found I had to change it to pass in the variable by reference so that it could be updated, as later portions of sosend() depend on it being updated in order to figure out what flags to pass to pru_send() with respect to PRUS_MORETOCOME, as well as for the (resid && space > 0) condition for the main loop. In your revised version, 'space' isn't updated in sosend() after calling m_uiotombuf(), which on a casual read, suggests that PRUS_MORETOCOME will no longer get set on the last pass into pru_send(), and that the loop may go an extra time and pass more data into TCP than there is room in the socket send buffer. I may be reading wrong, I've not had time to look in any detail, but that was my experience, so you may find you need to pass send by reference, as I do in sosend_copyin(), for the same reason.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: Much improved sosend_*() functions
    ... In your revised version, 'space' isn't updated in sosend() after calling m_uiotombuf, which on a casual read, suggests that PRUS_MORETOCOME will no longer get set on the last pass into pru_send, and that the loop may go an extra time and pass more data into TCP than there is room in the socket send buffer. ... I may be reading wrong, I've not had time to look in any detail, but that was my experience, so you may find you need to pass send by reference, as I do in sosend_copyin, for the same reason. ...
    (freebsd-current)
  • Re: StackOverflow Exception in JNI
    ... > I have a loop written in C/JNI which calls back a Java object (which ... temporary objects in your native method and then return a valid ... reference without thinking too much about these issues. ...
    (comp.lang.java.programmer)
  • Re: Looping-related Memory Leak
    ... memory leak / balloon for reasons I cannot figure out. ... end of the loop. ... reference count never reaches zero, and they remain alive until the ... the generational collector doesn't break cycles that involve ...
    (comp.lang.python)
  • Re: dynamic form validation / multiple forms
    ... for diagnosing the problems that produce errors on the browser. ... part is redundant as soon as you are passing the reference to the form ... of the form element but then using that name to look-up ... global variables a loop counters is particularly problematic as it ...
    (comp.lang.javascript)
  • Re: Holding Returned Data in Arrays
    ... According to the docs foreach uses the IEnumerable/IEnumerator interface ... so it will have to store the reference ... > Or I could hold that output in an array and loop through that collection: ... I always thought GetFiles() would be called once and then the output ...
    (microsoft.public.dotnet.framework.clr)