121–130 of 189 posts
Earlier quoted context omitted.
I remember when people used to say "you don't need threads, just use fork"!
What do they say now , out of curiosity?
Point is, some people don’t like threads and probably never will. Other people like threads and probably always will. Some languages have threads and many other programming models and then everyone is happy. I want the people who like threads to be happy in JS.
JS already has a proper concurrency model which is the event loop. What it doesn't have is a model for parallelism. It's important to understand the difference! It can be hard to grasp at first, because few people make the proper distinction. If you're new to the subject, don't take my word on it, but watch the talk "Concurrency is not parallelism" by Rob Pike[0]. It's highly recommended. Learning a language that mak…
JS the language has about as much to say about concurrency as C does.
Earlier quoted context omitted.
I think it would be weird if objects were thread-restricted by default. Concurrency is most fun when it's easy for a thread to access an object it wants.
I think the proposal was to thread-restrict variables, not objects. (Or more precisely, any variable is either restricted to a thread or guarded by a lock.) So it wouldn't actually stop you from accessing any object you want, as long as you can reach it from something in scope. But it also might not be a very useful safety guarantee.
It’s interesting to also have a function like that for properties and/or variables.
Earlier quoted context omitted.
WebKit does a lot of fine grained parallelism. I think you’re way too casually dismissing how awesome shared memory is.
With all due respect, no, it doesn't do fine grained parallelism in the areas I described. Do I think it would be impossible to add parallel styling or layout to WebKit? No. Do I think it would be difficult? Absolutely, primarily because of the difficulty of finding all the concurrency hazards in existing objects and making them thread-safe. It would be easier with a type system that automatically checks for and high…
Also, shared memory with no type system help is a proven technique that is used in shipping software and has been for a long time. This leads me to believe that it would be easier to use our existing full shared memory approach to implementing parallel layout than it would be to use your technique. Just the fact that some research experiment did use a type system and concurrency does not mean that this is actually better than the alternative. It just means that it is an alternative.
As for finding concurrency hazards when making things concurrent, you’re sorta talking to the right guy. That’s my bread and butter. Like every hard thing, it becomes easy with practice. Maybe type system help is for people who don’t practice enough.
Earlier quoted context omitted.
Of course not, and hopefully it will come to V8, but its mere existence does not preclude enhancing JavaScript, any more than the existence of PInvoke or JNI precludes enhancing .NET and Java. When people say "JS shouldn't support feature X", when feature X is supported in every other serious language, I can't help but guess that their real problem is with JS itself, and they just don't think people should be using i…
Well for me it adds complexity to JS. One nice thing about JS is that it is single threaded and you don't have to deal with locks or inconsistencies there. An entire class of problems goes away, and since JS event loop is reasonably fast as it is, it's pretty nice not having to worry about concurrency.
Earlier quoted context omitted.
Of course you can. You can implement anything on top of threads, especially non-determinism, race conditions and deadlocks.
Event loops have these too, they just go by different names: * non-determinism -> order in which setTimeouts run * race conditions -> callbacks happen in an unexpected order * deadlock -> broken callback chain
Earlier quoted context omitted.
Event loops have these too, they just go by different names: * non-determinism -> order in which setTimeouts run * race conditions -> callbacks happen in an unexpected order * deadlock -> broken callback chain
Yeah, but nobody relies on the execution order of disparate callbacks to achieve their results in JS. You're going to get burned in like two seconds if you try to do anything you listed. Lower level concurrency primitives in other languages allow developers to build fragile solutions which work 99% of the time until they deadlock and everything blows up. The concurrency model in JS is very explicit about being "no gu…
Earlier quoted context omitted.
"Concurrently" means "at the same time", both in English and in CS. One way to make it appear as if you have concurrency is to timeslice. One really bad way to do this is to have the timeslicing granule be computations of unbounded length with no preemption. I agree with you that it's valid to refer to event loops as a kind of concurrency. I would call it a very primitive and low-quality kind of concurrency. But it's…
> "Concurrently" means "at the same time", both in English and in CS. One way to make it appear as if you have concurrency is to timeslice. For one, the CS literature defines concurrency as not necessarily being at the same time. Second, timeslice , by definition, is not at the same time. Hence the need to use quotes there. Concurrently does not mean "at the same time" any more than "timeslice" implies. > But it's no…
Event loops are not like that. They run tasks to completion before starting other tasks and indeed the whole point of how you leverage an event loop is to take advantage of the fact that other things don’t happen at the same time. I would prefer to say other things don’t happen concurrently, and you would have understood my meaning.
It’s not correct to have used the word “parallel” in that context since my example only needs one CPU.
I think it’s ok to think of event loop interleaving bugs as being concurrency bugs, but insisting that event loops are proper instance of concurrency is diluting the terminology too much IMO. Hence I much refer to use concurrency to mean the case where the interleaving granule is not under the programmer’s control.
Earlier quoted context omitted.
Even loop is not concurrency. Just because concurrency and parallelism are different does not meant that concurrency and event loops are the same.
How? Explain please. https://en.wikipedia.org/wiki/Concurrency_(computer_science) "order-independent components", which makes sense for the Event loop.
For example, I can say that when a task executes on an event loop, no other tasks are executing concurrently to it because the event loop executes tasks sequentially.
Please, no. Shared-by-default heap memory is one of the greatest mistakes ever made in language design. We need a better design justification than it's the easiest thing to implement right now.
The justification is that when you have an array of 100000 elements and split it into into isolated chunks that can be processed without any synchronisation and then marshall it into json and then actually do the computation and then marshall the result into a json string and marshall it back into a javascript array is very wasteful. Heck even when I'm passing immutable messages I'd still implement it via shared memo…
No need for the mess that is (in my opinion) true shared memory.