[erlang-questions] gen_tcp nonblocking send

[Daniel Ginsburg]

Per Hedeland wrote:
>> Internally, sockets are non-blocking (see 
>> erts/emulator/drivers/common/inet_drv.c), but as far as I understand, 
>> gen_tcp and all the underlying libraries like prim_inet expose only 
>> blocking send API to erlang processes.
>>     
>
> And *you* don't really want non-blocking send (in the O_NDELAY sense)
> anyway, but async send. Looking at prim_inet will tell you how to get
> it, but I think in this case the "de-sync'ing" intermediate process is a
> reasonable solution. Async accept is another story...
>
> --Per
>   
Sure, solution with intermediary worked just fine.

Thought, I don't understand why I shouldn't want nonblocking send? In a 
sense of O_NDELAY+select/poll/whatever

Indeed, if I were able to get
1) indication that send buffer is full in form of return code from send call
2) indication that some space in send buffer was freed up in form of 
message to my process
I could implement what I want without any intermediary.

It must be my previous background that makes me want this mode of 
operation. I had to wrap my mind a bit around intermediary process. I 
think it's ok, though. I have learnt something today.