[erlang-questions] Non-blocking sends in gen_tcp?

[Witold Baryluk]

On 03-11 11:19, Cayle Spandon wrote:
> Does gen_tcp provide a mechanism for non-blocking sends, similar to the
> traditional send and select/poll calls in Unix, in the following sense:
> 
> -1- When you call gen_tcp:send() with N bytes and flow-control kicks in,
> gen_tcp:send()returns immediately (i.e. does not block, not even for some
> small time-out). The return value indicates that flow-control was invoked
> and gives some indication of what subset of bytes was accepted (e.g. by
> returning the remaining unsent binary). This is similar to Unix send()
> returning EAGAIN.
> 
> -2- Some mechanism to inform the sending process that the socket is ready to
> send more data, e.g. an Erlang message. This is similar to Unix select()
> reporting that a socket is ready-to-send.
> 
> I have considered the option of creating an Erlang process dedicated to
> sending messages over the socket and using blocking gen_tcp:send calls in
> that process. For various reasons  (related to the fact that a send may have
> to be interruped by some other activity) this is not an option for me.
> 
> I found some references to the prim_inet module on Google, but evidently
> that is not an officially documented module.

I'm currently using some magic functions from prim_inet directly, for
asynchrounous recv and send. I will much more happy if this functions
(like async_accept, async_read, port_command) will be officially supported
and documented. Or better way for handling it should be presented.



-- 
Witold Baryluk
JID: witold.baryluk // jabster.pl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090311/9810866c/attachment.bin>