7 ms·

You say fun, but what you mean is twisted mess.

by richardwhiuk 9y ago

pizlonator 9y ago
WebKit uses threads. WebKit is not a twisted mess.
- coldtea 9y ago
  WebKit needs tons of extra effort to keep it from being a twisted mess precisely because it uses threads.
  - pizlonator 9y ago
    Can you be very specific?
    - coldtea 9y ago
      When told that multi-threaded access is hard and messy, "X program uses threads and it's not a mess" is not an argument -- for one because nobody said X program is a mess. Threads being messy is not a transitive property. Nobody doing threads ever said that they are not messy or that multi-thread access and locking et al are easy.
      - pizlonator 9y ago
        I do threads and I just said that they are not messy.
        coldtea 9y ago
        Well, nobody sane then if I'm allowed the Scotsman! People also defend all kinds of dangerous constructs or practices blaming other programmers for not being good enough to use them even though statistically even the best programmers suffer from problems derived from them (e.g. buffer overflows, or in the case of threads race conditions, starvation, etc.). And since we're particularly talking about adding threads to Javascript, here's the opinion of the creator of Javascript itself on threads: You must be this tall to hack on threaded systems, and that means most programmers should run away crying. But they don’t. Instead, as with most other sharp tools, the temptation is to show how big one is by picking up the nearest ST code and jamming it into a MT embedding, or tempting race-condition fate otherwise. Occasionally the results are infamous, but too often, with only virtual fingers and limbs lost, no one learns. Threads violate abstractions six ways to Sunday. Mainly by creating race conditions, deadlock hazards, and pessimistic locking overhead. And still they don’t scale up to handle the megacore teraflop future. https://brendaneich.com/2007/02/threads-suck/ Also, are you the author of TFA? That sure speaks to your skills, but that doesn't mean standard definitions (e.g. on concurrency) or traditional consensus (e.g. on threads being messy) don't apply.
        olliej 9y ago
        Appealing to authority isn't a valid argument. Brendan and I have had many discussions about the nature of threading in JS. The reality is that to get high performance in JS on modern (and future afaict) is that JS will need to have some lower cost threading mechanism than that provided by workers. If you read the article you'll see that there isn't any way to mismatch lock/unlock. The other massive footgun is the for whatever reason people insist on creating standard libraries that are not thread safe (collections, apparently bigint in java?). JS is never going to have completely undefined behavior, but non-determinism already exists. Is concurrent code easier to screw up than single thread? yes. Is that cost enough to discount the possibility of ever having threads? I don't know. The article goes one way, you clearly go the other.
        coldtea 9y ago
        >Appealing to authority isn't a valid argument. Calling out "argument from authority" when someone posted actual arguments an authority made is even less valid. >The reality is that to get high performance in JS on modern (and future afaict) is that JS will need to have some lower cost threading mechanism than that provided by workers. Perhaps, but this is an orthogonal concern as to the issues with threads themselves (not to mention with an environment that has since forever assumed a single thread of execution).
        pizlonator 9y ago
        I think that someone taught you the wrong definition of concurrency. I’m just trying to help you learn the right one.
      - dboreham 9y ago
        Oh ffs I feel like I'm back in 1994 or so...
        coldtea 9y ago
        Because there was some huge breakthrough since eliminating threading issues? (If you answer just use Erlang, CSP or any other variation, well, my point exactly).
        pizlonator 9y ago
        The only breakthrough is that some of us learned to use threads. Apparently some of us didn’t.
        coldtea 9y ago
        Apparently, after decades of CS and tons of costly errors, some of us still haven't learned than issues like memory safety, race conditions, etc are either handled at the language level, or are dangerous for everybody -- and that those that consider themselves immune to them because they "know how to use them" and are "better programmers" are just deluded.
      - pizlonator 9y ago
        You just called WebKit a twisted mess. I asked you for examples. Looks like you don’t have any. Like I said, WebKit uses threads and it’s great. Maybe some day you will also learn to use threads.
        deleted 9y ago
        [deleted]
        Jtsummers 9y ago
        coldtea literally never said that WebKit was a twisted mess. robertwhiuk, responding to you, referenced using "twisted mess" pizlonator: 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. robertwhiuk: You say fun, but what you mean is twisted mess. No reference yet to WebKit until your response: WebKit uses threads. WebKit is not a twisted mess. coldtea chimed in with this: WebKit needs tons of extra effort to keep it from being a twisted mess precisely because it uses threads. What is that "extra effort"? Discipline, care, good work. coldtea does not call WebKit a twisted mess. In fact, they seem to be saying the opposite. That it is not a twisted mess despite using threads. You have some good points in this discussion, generally. But you should at least be honest in your characterization of other people's comments. Maybe some day you will also learn to use threads. Maybe someday you will also learn reading comprehension.
        pizlonator 9y ago
        coldtea was unable to come up with a single example of where WebKit is a twisted mess or even needs effort to avoid becoming one. No matter what kinds of semantics you throw at this, I think it’s the case that these arguments against threads lack basis.
        coldtea 9y ago
        >coldtea was unable to come up with a single example of where WebKit is a twisted mess That's because coldtea (me) never said it IS a twisted mess. What I said is that with threads, WebKit (and any program for that matter) needs extra effort to not be a twisted mess. Exactly what the parent explained again, and you don't seem to have got even this second time. Why that is the case (in other words, why parallel programming with threads is harder and requires more effort than without), is CS 101. Some reasons? Synchronization and scheduling access to resources. Race conditions -- data Races, deadlocks, etc. Starvation. Balancing the number of threads (diminishing returns). Locking subtleties. VM/state/etc overhead of threading. In fact you'd be hard pressed to find seasoned programmers that would disagree that threads are problematic and require extra caution. Heck: "Although threads seem to be a small step from sequential computation, in fact, they represent a huge step. They discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism. Threads, as a model of computation, are wildly nondeterministic, and the job of the programmer becomes one of pruning that nondeterminism" -- https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
  - LeoNatan25 9y ago
    Any well written software requires effort to properly design and maintain. What’s the argument here? “Don’t give them shotguns, they might shoot themselves”?
    - PeCaN 9y ago
      Don't load the shotguns, turn off the safety, point it at their foot and tell them “please be careful”.
- pcwalton 9y ago
  I mean, you could say the same thing about assembly language programs. "Either static or dynamic typing is needed to prevent large programs from becoming a twisted mess" is a pretty uncontroversial statement today, despite the fact that there were some very high quality large assembly language programs written back in the DOS days. Besides, WebKit doesn't do fine-grained parallelism on the level of parallel styling or parallel layout. My colleague Manish came up to me after a long back-and-forth conversation with bz to figure out which objects were thread-safe and told me "the biggest lesson of Stylo is that adding parallelism to a previously large sequential C++ project is basically impossible". That's because large-scale projects invariably fail to properly document the precise synchronization invariants that each object must uphold in order to function properly. They settle for blanket statements like "the entire render tree is single threaded only" which, while conservatively a correct statement, essentially gives up on fine-grained tracking and makes it very hard to add parallelism later. By contrast, when you lift concurrency guarantees into the type system, the compiler essentially enforces that the documentation on thread safety is always up to date. This makes it way easier to start with sequential code and add parallelism (and/or concurrency) later as real-world profiling indicates fruitful optimization opportunities. I think you're way too casually dismissing the very real problems that unrestricted shared state has.
  - pizlonator 9y ago
    WebKit does a lot of fine grained parallelism. I think you’re way too casually dismissing how awesome shared memory is.
    - dbaupp 9y ago
      Servo, which pcwalton works on, is largely motivated by the awesomeness of shared memory.
    - pcwalton 9y ago
      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 highlights such problems. Such a system is precisely what I'm advocating. And I'm not saying not to use shared memory. I'm saying that shared memory should be controlled by some sort of static or dynamic type system that enforces proper locking or immutability as the case may be. Such a system is hardly a far-fetched idea, as we're successfully using one right now in the style system of nightly Firefox.

You say fun, but what you mean is twisted mess.

pizlonator 9y ago

WebKit uses threads. WebKit is not a twisted mess.

coldtea 9y ago
WebKit needs tons of extra effort to keep it from being a twisted mess precisely because it uses threads.
- pizlonator 9y ago
  Can you be very specific?
  - coldtea 9y ago
    When told that multi-threaded access is hard and messy, "X program uses threads and it's not a mess" is not an argument -- for one because nobody said X program is a mess. Threads being messy is not a transitive property. Nobody doing threads ever said that they are not messy or that multi-thread access and locking et al are easy.
    - pizlonator 9y ago
      I do threads and I just said that they are not messy.
      - coldtea 9y ago
        Well, nobody sane then if I'm allowed the Scotsman! People also defend all kinds of dangerous constructs or practices blaming other programmers for not being good enough to use them even though statistically even the best programmers suffer from problems derived from them (e.g. buffer overflows, or in the case of threads race conditions, starvation, etc.). And since we're particularly talking about adding threads to Javascript, here's the opinion of the creator of Javascript itself on threads: You must be this tall to hack on threaded systems, and that means most programmers should run away crying. But they don’t. Instead, as with most other sharp tools, the temptation is to show how big one is by picking up the nearest ST code and jamming it into a MT embedding, or tempting race-condition fate otherwise. Occasionally the results are infamous, but too often, with only virtual fingers and limbs lost, no one learns. Threads violate abstractions six ways to Sunday. Mainly by creating race conditions, deadlock hazards, and pessimistic locking overhead. And still they don’t scale up to handle the megacore teraflop future. https://brendaneich.com/2007/02/threads-suck/ Also, are you the author of TFA? That sure speaks to your skills, but that doesn't mean standard definitions (e.g. on concurrency) or traditional consensus (e.g. on threads being messy) don't apply.
        olliej 9y ago
        Appealing to authority isn't a valid argument. Brendan and I have had many discussions about the nature of threading in JS. The reality is that to get high performance in JS on modern (and future afaict) is that JS will need to have some lower cost threading mechanism than that provided by workers. If you read the article you'll see that there isn't any way to mismatch lock/unlock. The other massive footgun is the for whatever reason people insist on creating standard libraries that are not thread safe (collections, apparently bigint in java?). JS is never going to have completely undefined behavior, but non-determinism already exists. Is concurrent code easier to screw up than single thread? yes. Is that cost enough to discount the possibility of ever having threads? I don't know. The article goes one way, you clearly go the other.
        coldtea 9y ago
        >Appealing to authority isn't a valid argument. Calling out "argument from authority" when someone posted actual arguments an authority made is even less valid. >The reality is that to get high performance in JS on modern (and future afaict) is that JS will need to have some lower cost threading mechanism than that provided by workers. Perhaps, but this is an orthogonal concern as to the issues with threads themselves (not to mention with an environment that has since forever assumed a single thread of execution).
        pizlonator 9y ago
        I think that someone taught you the wrong definition of concurrency. I’m just trying to help you learn the right one.
    - dboreham 9y ago
      Oh ffs I feel like I'm back in 1994 or so...
      - coldtea 9y ago
        Because there was some huge breakthrough since eliminating threading issues? (If you answer just use Erlang, CSP or any other variation, well, my point exactly).
        pizlonator 9y ago
        The only breakthrough is that some of us learned to use threads. Apparently some of us didn’t.
        coldtea 9y ago
        Apparently, after decades of CS and tons of costly errors, some of us still haven't learned than issues like memory safety, race conditions, etc are either handled at the language level, or are dangerous for everybody -- and that those that consider themselves immune to them because they "know how to use them" and are "better programmers" are just deluded.
    - pizlonator 9y ago
      You just called WebKit a twisted mess. I asked you for examples. Looks like you don’t have any. Like I said, WebKit uses threads and it’s great. Maybe some day you will also learn to use threads.
      - deleted 9y ago
        [deleted]
      - Jtsummers 9y ago
        coldtea literally never said that WebKit was a twisted mess. robertwhiuk, responding to you, referenced using "twisted mess" pizlonator: 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. robertwhiuk: You say fun, but what you mean is twisted mess. No reference yet to WebKit until your response: WebKit uses threads. WebKit is not a twisted mess. coldtea chimed in with this: WebKit needs tons of extra effort to keep it from being a twisted mess precisely because it uses threads. What is that "extra effort"? Discipline, care, good work. coldtea does not call WebKit a twisted mess. In fact, they seem to be saying the opposite. That it is not a twisted mess despite using threads. You have some good points in this discussion, generally. But you should at least be honest in your characterization of other people's comments. Maybe some day you will also learn to use threads. Maybe someday you will also learn reading comprehension.
        pizlonator 9y ago
        coldtea was unable to come up with a single example of where WebKit is a twisted mess or even needs effort to avoid becoming one. No matter what kinds of semantics you throw at this, I think it’s the case that these arguments against threads lack basis.
        coldtea 9y ago
        >coldtea was unable to come up with a single example of where WebKit is a twisted mess That's because coldtea (me) never said it IS a twisted mess. What I said is that with threads, WebKit (and any program for that matter) needs extra effort to not be a twisted mess. Exactly what the parent explained again, and you don't seem to have got even this second time. Why that is the case (in other words, why parallel programming with threads is harder and requires more effort than without), is CS 101. Some reasons? Synchronization and scheduling access to resources. Race conditions -- data Races, deadlocks, etc. Starvation. Balancing the number of threads (diminishing returns). Locking subtleties. VM/state/etc overhead of threading. In fact you'd be hard pressed to find seasoned programmers that would disagree that threads are problematic and require extra caution. Heck: "Although threads seem to be a small step from sequential computation, in fact, they represent a huge step. They discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism. Threads, as a model of computation, are wildly nondeterministic, and the job of the programmer becomes one of pruning that nondeterminism" -- https://www2.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
- LeoNatan25 9y ago
  Any well written software requires effort to properly design and maintain. What’s the argument here? “Don’t give them shotguns, they might shoot themselves”?
  - PeCaN 9y ago
    Don't load the shotguns, turn off the safety, point it at their foot and tell them “please be careful”.
pcwalton 9y ago
I mean, you could say the same thing about assembly language programs. "Either static or dynamic typing is needed to prevent large programs from becoming a twisted mess" is a pretty uncontroversial statement today, despite the fact that there were some very high quality large assembly language programs written back in the DOS days. Besides, WebKit doesn't do fine-grained parallelism on the level of parallel styling or parallel layout. My colleague Manish came up to me after a long back-and-forth conversation with bz to figure out which objects were thread-safe and told me "the biggest lesson of Stylo is that adding parallelism to a previously large sequential C++ project is basically impossible". That's because large-scale projects invariably fail to properly document the precise synchronization invariants that each object must uphold in order to function properly. They settle for blanket statements like "the entire render tree is single threaded only" which, while conservatively a correct statement, essentially gives up on fine-grained tracking and makes it very hard to add parallelism later. By contrast, when you lift concurrency guarantees into the type system, the compiler essentially enforces that the documentation on thread safety is always up to date. This makes it way easier to start with sequential code and add parallelism (and/or concurrency) later as real-world profiling indicates fruitful optimization opportunities. I think you're way too casually dismissing the very real problems that unrestricted shared state has.
- pizlonator 9y ago
  WebKit does a lot of fine grained parallelism. I think you’re way too casually dismissing how awesome shared memory is.
  - dbaupp 9y ago
    Servo, which pcwalton works on, is largely motivated by the awesomeness of shared memory.
  - pcwalton 9y ago
    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 highlights such problems. Such a system is precisely what I'm advocating. And I'm not saying not to use shared memory. I'm saying that shared memory should be controlled by some sort of static or dynamic type system that enforces proper locking or immutability as the case may be. Such a system is hardly a far-fetched idea, as we're successfully using one right now in the style system of nightly Firefox.