I understand that updating object in shared memory need synchronization and even with in-memory database task in general there will be a global lock (not per-object because transaction will spread by different tables and object) and only one process will write to memory so I think just global lock will be enough for most tasks. But reading from shared memory is safe and there is no reason to not use all cpu cores to achieve more performance and that's why go and other languages will overcome js in this tasks. But I hope js will be able to compete and new features like SharedArrayBuffer and atomics seems like moving forward javascript to the right direction and I don't see why "JavaScript is not designed for such purposes.". Does SharedArrayBuffer supposed to do zero copy reading in different workers? How it implemented - by multiple threads or maybe it already using shared memory and different process?
On Mon, Jan 8, 2018 at 6:04 PM, Jakob Kummerow <jkumme...@chromium.org> wrote: > No, you cannot simply share all memory to get multi-threading. For > safely/correctly working with shared memory, you need > locking/synchronization primitives as well as certain guarantees in the > language's memory model. JavaScript is not designed for such purposes. > > > On Mon, Jan 8, 2018 at 3:52 PM Bogdan <bgnor...@gmail.com> wrote: > >> I don't know all details, I just a regular node developer who came up >> with idea of "threading" in js and hope anybody with deep knowledge will >> clarify some things. Javascript have old problem of lacking threading and >> all advices of using multiple processes doesn't help because there are >> important tasks (for example in-memory database or managing application >> cache) which needs shared memory to utilize all cpu cores and having full >> copy of that memory and synchronizing it by coping data over channels >> doesn't make sense. Recently I've found out an interesting linux feature >> like shader memory with shm_open and mmap which can allow zero-copy and >> zero-overhead access to shared memory from different processes. There are >> also some node modules which exposes this feature to javascript but seems >> like all they can do is exposing shared memory to javascript as an array >> which means all object managing, garbage collector, and other useful >> features we need to do all by ourselves. So I am wondering can v8 (if >> cannot now, maybe in it will with little hacking) allow to just map all >> heap into shared buffer so we can use the same objects from another process >> without copying? >> >> -- >> -- >> v8-users mailing list >> v8-users@googlegroups.com >> http://groups.google.com/group/v8-users >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to v8-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -- > -- > v8-users mailing list > v8-users@googlegroups.com > http://groups.google.com/group/v8-users > --- > You received this message because you are subscribed to a topic in the > Google Groups "v8-users" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/v8-users/2Z2UFFQrziE/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > v8-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
