[erlang-questions] gen_tcp nonblocking send

[Igor Ribeiro Sucupira]

On Thu, May 1, 2008 at 7:34 PM, Igor Ribeiro Sucupira <igorrs@REDACTED> wrote:
> On Thu, May 1, 2008 at 5:01 PM, Valentin Micic <valentin@REDACTED> wrote:
>  > >
>  >  > You didn't read my suggestion carefully enough - try again.
>  >  >
>  >
>  >  You're right -- I did not read it carefully enough. Your suggestion would
>  >  not develop a scheduling problem. However, after reading it again, I'm
>  >  really not sure why would O_NDEALY be such an evil thing, if it is
>  >  implemented as a separate function call (and not as a flag), that would
>  >  return a binary containing unsent octets. It would certainly help (in this
>  >  case not-so) intelligent queuing on the caller side -- unlike your sender
>  >  that needs to do pre-emptive queuing, until it receive's ack from "relay",
>  >  it would need to queue only unsent octets, right?
>
>
>  I don't really see the point of dealing with "partial sends" and
>  queuing unsent octets, if all you want is to send the whole message.
>  It doesn't look necessary in a concurrent environment with lightweight threads.
>
>  As for O_NDELAY, I still think it could be useful in some situation,
>  but not in this case,

In fact, it maybe could make a small difference here.

In the implementation we've suggested, we could have this:
t0) Start sending {k1, v0}. Local buffer is full. send-process blocked.
t1) k1 updated to v1.
t2) Local buffer has space. {k1, v0} being sent.
t3) k1 updated to v2.
t4) {k1, v0} sent. Start sending v2.

Maybe O_NDELAY would allow us to do this:
t0) Start trying actively (non-blocking) to send {k1, v0}. Local buffer is full.
t1) k1 updated to v1. Give up on v0. Now we're trying to send {k1, v1}.
t2) Local buffer has space. {k1, v1} being sent.
t3) k1 updated to v2.
t4) {k1, v1} sent. Start sending v2.


Which is clearly better.

Igor.

> for a similar reason: you'll be sending the data
>  anyway, as soon as you can do it. So, why not just spawn a process to
>  do exactly that wait-and-send?
>
>  Igor.
>