[erlang-questions] what is the "race condition bug in core Erlang" mentioned by @damienkatz?
Sat Jan 12 10:57:35 CET 2013
On Fri, Jan 11, 2013 at 11:11 PM, Max Lapshin <max.lapshin@REDACTED> wrote:
> Ok, my question is: why do they think that fixing the same bug in C
> program, written around libuv will be easier?
> I've written a video streaming server in ObjectiveC and I can tell how
> hard is to find bugs in single threaded callback-style program.
> So, this is a hard-to-find-bug. When you fix all easy-to-find-bugs there
> are only hard bugs. Erlang has all easy bugs fixed, left only hard bugs.
> This is why we will hear more and more that some horrible bug inside Erlang
> VM is found and fixed.
> Frankly speaking, I dont understand complaints about erlang performance,
> when half of your system is written in C. Fast path is coded in C and
> erlang has excelent capabilities for it.
> I've used such approach to
> 1) capture UDP packets in fast manner with my own hand-crafted gen_udp
> 2) use direct mmap access (which is impossible in Java):
> 3) write USB video capture:
> 4) write my own database for storing ticks:
> So I really don't understand the problem.
> You are writing a database server and use erlang prim_file? Sorry, are you
> really sure that you are writing a database server or you are just playing
> a new shiny toy?
> Was it a problem to open very simple erlang sources and find that
> prim_file is designed for non-blocking, not for speed?
> For example, when I understood that erlang's gen_udp cannot accept 10K of
> messages per second, I've rewritten it in C in a couple of days. If I was
> writing a database server with high requirements to disk IO, I would
> definitely use blocking but fast direct file access.
> But I don't see any of these reasonings in Damien's post, I see only
> "created cultures that focus on the wrong things". Yes, of course C created
> a culture which is focused only on right things.
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions