[erlang-questions] C nodes and select loops

21 views
Skip to first unread message

David Welton

unread,
Nov 14, 2012, 11:05:48 AM11/14/12
to Erlang Questions
Hi,

I expected to find an answer to this one via Google, but I didn't.

I'm looking at the C node example, and it does:

while (loop) {
got = erl_receive_msg(fd, buf, BUFSIZE, &emsg);

Which is ok if you can sit around waiting on incoming Erlang messages,
but say you want to work with a select loop (or whatever form of
polling/events) where you can get events from other places, as well as
from other Erlang nodes.

The ei_connect man page says:

As with all other ei functions, you are not expected to put the socket
in non blocking mode yourself in the program. Every use of non blocking
mode is embedded inside the timeout functions. The socket will always
be back in blocking mode after the operations are completed (regardless
of the result). To avoid problems, leave the socket options alone. Ei
will handle any socket options that need modification.

That makes me a bit wary... Granted, there are the _tmo options, but
I just wanted to ask around for advice on best practices for something
like this.

Thanks
--
David N. Welton

http://www.dedasys.com/
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

Michael Truog

unread,
Nov 14, 2012, 12:06:49 PM11/14/12
to David Welton, Erlang Questions
The main problem is handling the is calling the ei_receive (or one of the variations on this function) often enough so no node ticks are missed, such that you don't cause a nodesplit. This is the ERL_TICK shown in http://www.erlang.org/doc/tutorial/cnode.html , mentioned here http://erlang.org/doc/man/ei_connect.html#ei_receive . So, this provides a maximum time you have to process internal events, unless you create separate threads to do work internally, within your cnode. You can always set the net ticktime to be longer, but I have found that to cause problems with links between nodes (due to assumptions that seemed to exist, which may not exist now). If you are doing integration like this, consider looking at CloudI (http://cloudi.org), which helps to avoid cnode integration (cnode integration limits system scalability, because of the net ticktime).

Serge Aleynikov

unread,
Nov 14, 2012, 12:18:56 PM11/14/12
to David Welton, Erlang Questions
Unfortunately this is a shortcoming of the erl_interface library - it doesn't offer any non-blocking alternatives of socket-handling functions (e.g. erl_connect and erl_receive_msg).

If you need that and are flexible about using C++ in your project, you can consider the following project which implements asynchronous communication with Erlang nodes:

https://github.com/saleyn/eixx

Serge
Reply all
Reply to author
Forward
0 new messages