Erlang, port_control, linked-in driver and badarg

port_control function may return badarg if control function (implemented in linked-in driver) returns value which not equals number of bytes filled in rbuf.

How to connect to erlang node on remote machine

I'm very new in Erlang node and just studing it.
I have some trouble with connecting Erlang nodes on remote machine. And I found following solution:
Erlang (or erlang shell) should be started with same cookie on remote machines, i.e.:

erl -name node1 -setcookie my-cookie
erl -name node2 -setcookie my-cookie

valgrind, dlopen and debug info

You may encounter with following situation: you profile your application with valgrind, run the KCachegrind and you are not seeing debug info for some your modules.

As wrote in the internets this is a bug (http://bugs.kde.org/show_bug.cgi?id=142086, http://bugs.kde.org/show_bug.cgi?id=79362).

In my case I can avoid this bug as following: disable unloading of modules via dlclose.

SPE stalls and power saving

If the write channel is blocking , then a wrch instruction that is issued when the count for that channel is equal to zero will stall the SPE. Stalling on a wrch instruction can be useful because it saves power.

asio and asynchronous file processing

Some weeks ago I began tests of reading amount numbers of floats from a text file. I wrote simple test framework and test and compare different methods of file reading. Alex advises me to try the asio in my tests. He advises me to try a version from CVS but I decide to try the latest version – 1.1.0. I use Windows and all my experiments related to it.

Asio has class asio::windows::basic_stream_handle that allows to read stream of data from file. But in the latest version this class has a bug – file pointer not moved and all subsequent calls read data from begin of the file.

The last version from CVS has class asio::windows::basic_random_access_handle that allows to read block (or stream) of data from arbitrary position in file. Using this class I can make my tests.

Test file has following structure:

section_name
  float float float float
  float float float float
  …
  float float float float
/

section_name
  float float float float
  …

How we read data from the file using the asio? Asio provide functions and classes for read data in two modes – a synchronous and asynchronous.

In my tests I use a hybrid scheme – I read data synchronously for locate section in file and use the asynchronous mode and double-buffering idiom for process float list. Also I run tests only on the first section so code for location section has a small bug.

And now super prize for patient readers – source code of my tests, full source (sorry, for filefactory).

And so, first I define reading handler that will be invoked by the asio kernel when read data will be ready to process. In my sources it's a read_handler function.

Second, before start read data we should define condition with reading will stop. In my sources it's a complete_condition function.

Third, we should define destination of the read data. In the most examples boost::array used or asio::streambuf. boost::array I can't use because reading data without buffering requires that data buffer should be sector aligned. asio::streambuf has its own disadvantages. And so, I use raw pointers.

As I wrote above I early had written realization of test using standard Windows API. I compare results that were obtained and I can conclude that a realization of the asio library is a very and very good.

test of random access from file without buffering (FILE_FLAG_NO_BUFFERING)
On the horizontal bar - size of data buffer (bytes), on the vertical bar - data transfer rate (MB/s)

And also I will choose the asio for all my following projects that require file processing first.

asio::io_service::reset hint

I can advise to call asio::io_service::reset before each call of asio::io_service::run:

This function must be called prior to any second or later set of invocations of the run(), run_one(), poll() or poll_one() functions when a previous invocation of these functions returned due to the io_service being stopped or running out of work. This function allows the io_service to reset any internal state, such as a "stopped" flag.

This may prevent you from some stupid errors.

asio::windows::basic_stream_handle - 2

Also, we can 'hack' windows::basic_stream_handle. If we add following code info file win_iocp_handle_service.hpp after line 691 and basic_stream_handle will works as I expect =)

I don't understand all reasons why asio developers chose different way for solving this 'problem'.

ptr.get()->Offset = boost::uint64_t (handler.total_transferred_) & 0xFFFFFFFF; ptr.get()->OffsetHigh = (boost::uint64_t (handler.total_transferred_) >> 32) & 0xFFFFFFFF;

_Winnie C++ Colorizer