[erlang-questions] why is mmap so darn difficult

[Tim Watson]

Hi Max!

On 12 Jun 2013, at 08:32, Max Lapshin wrote:

> Tim, you are messing a bit about drivers and nifs.
> 
> There is absolutely no problem in implementing mmap for read in
> erlang. I have done so in erlyvideo, but refused.

It's both reads and writes that I want to handle. Think long (ish) term storage of data that gets written to sequentially, with multi reader who also read sequentially from a fixed point (so a seek to find the initial position, followed by more sequential reads).

> 
> Mmap is absolutely unpredictable. Access to memory can take several
> nanoseconds or several seconds. It is impossible to build a
> good service when you have such fluctuations.
> 

Interesting. That's not a situation I've come across before, but regardless, it is amortized costs that interest me on the whole. I can quite happily suffer the odd individual operation being slow, providing the overall inputs rates remain high.

> There is no problem in using file:pread and gen_tcp:send.

Sure, but it is fast writes that I care about. Do you think mmap is going to be problematic in that regard also? I certainly know of other uses of mmap (outside of Erlang) that claim writer rates of around 250Khz. I'm unconvinced I'll be able to replicate anything like that using basic file operations. Of course I could use an embedded database I suppose - that's something I've considered and have selected a couple of candidates - but then I loose the ability to use file:sendfile to push the data downstream later on. Perhaps this latter concern isn't a massive issue - since I've not benchmarked, I have no idea - but I need an embedded database with the minimum possible memory footprint, so I can't have something where all the keys need to fit in memory. The one that has come up as a choice has a NIF based driver too, which I'm totally unconvinced by, so I'll have to write my own driver anyway. Sigh...

> At least, erlyvideo can send several gigabits of video without mmap. It would be
> impossible to achieve it with mmap, because you will not be able to
> make it stable.
> 

Ok, so according to this,  for readers file:pread + normal socket APIs can achieve a high enough throughput. Now the problem is solely with writes. Erlyvideo does not, presumably, read gigabits of video from a socket, put them on disk for later reading *and* deliver them in 'as close to realtime as possible' to another live reader (socket) with minimal delay?

> So, with mmap: you don't need it. It is a bad technology.

I'll definitely take that experience you've had with it into consideration. Thanks.

Tim