How to do table lookups?

Vance Shipley <>
Wed Mar 3 20:05:46 CET 2004


Edmund,

You should look at erl_interface (ei specifically) which is a
C library you link with your C program which provides everything
you need to implement a "C node".  This way you can just send
atoms, integers, strings, etc. and receive them as normal in
your Erlang node.

}    <<First:1/binary, Rest/binary>> = Bytes,

The above will not work.  It should be:

    <<First:8/binary, Rest/binary>> = Bytes,

}  But this would seem slow (as we need to sequentially scan down the

Don't worry about it.

}  I thought of using the process dictionary, but this seemed to be the wrong

Just say no to the process dictionary.

}  Now I could create some kind of state variable (with all the appropriate
}  dictionaries), but this would be awkward to keep passing around, as it is
}  needed only at the lowest levels.
  
This is the way it's done.  You pass state data around like a hot potato.
It may seem awkward somehow but it has it's own beauty.  Erlang has no
global variables, get used to passing everything you need.

}  Should I create a process, and use message passing? This would seem to
}  consume extra overhead, and I would need to pass along a process ID
}  (unless I wanted to do a lookup each time) similar to the state idea.
  
This is what you do when multiple processes need access to the same 
data.  It's the way it works.  Quit worrying about performance.  
(However in this case it's the wrong approach).

}  Is there a better way?

Definetly use ei.  

Another word of advice; you should always assume you are doing the 
wrong thing if you write a receive statement (unless your name is
on the cover of the Erlang book).  Everything can and should be 
done with the standard behaviours.

  [This is rule of thumb advice for less than expert Erlang 
   coders.  Once you are an expert you can implement your own 
   behaviours]
 
In the case of C nodes this may seem necessary but it actually 
isn't.  Just have your ei program format it's messages appropriately
and make your Erlang program a gen_server/gen_fsm.  If you look at
gen_server.erl you'll see the messaghes it expects are of the form:

	{'$gen_cast', Msg}
	{'$gen_call', From, Msg}

While you're there look at how much is being done under the hood 
for you and you'll see why you should use a standard behaviour.

}     Port = open_port({spawn, "EXE"}, [stream, binary]).

Windows?  Can't help you.

	-Vance



More information about the erlang-questions mailing list