Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

FWIW: Node.js uses a buffer cache like this by default: https://github.com/joyent/node/blob/master/lib/buffer.js


It's a good thing Node.js doesn't have to worry about synchronization between threads... :)


Would the down-voters care to explain? I've pointed out how another platform deals with allocating raw memory buffers as it's relevant to the discussion.

I've made no claims of it being superior, and in fact, am largely using Go myself these days.


Using a shared buffer list isn't very efficient in a language with concurrency since you have to synchronize to take from/add to the list.


All heap access must be synchronized. Using pooled buffers may actually be faster because you can ensure that only one thread is accessing a specific pool. Just create a new pool, when a new thread is created.


Or, you know, each thread could allocate only when it needs something and handle its own recycling. Node.js has a particular advantage in that it isn't concurrent in any way (which, of course, has many other downsides.)


You can certainly build concurrent systems on top of Node, what it doesn't have is preemptive multi-threading, which sucks IMHO, but speaking of Go I also don't like that it does M:N multi-threading instead of 1:1 like the JVM, as the scheduling done is suboptimal.


Oh man, I'm pretty keen to write many types of subsystems, but thread scheduling?

I'll take stuff I don't want to mess with for 300, Alex.


> You can certainly build concurrent systems on top of Node

You sound so confident. Do you have any example of a system in JavaScript that has concurrent semantics?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: