7 Matching Annotations
  1. Apr 2021
    1. To prevent race conditions and deadlocks, we highly recommend that each of the communication channels is serviced on a separate thread that maintains its own client buffer state and messaging queue inside your application. Servicing all of the pseudoconsole activities on the same thread may result in a deadlock where one of the communications buffers is filled and waiting for your action while you attempt to dispatch a blocking request on another channel.
  2. Feb 2021
    1. The rationale is that it's actually clearer to eager initialize. You don't need to worry about timing/concurrency that way. Lazy init is inherently more complex than eager init, so there should be a reason to choose lazy over eager rather than the other way around.
  3. Nov 2020
    1. But you can still run into strange race conditions where the browser displays stale data depending on if some other unrelated code has caused a digest update to run after the buggy code or not.
  4. Sep 2020
    1. export let client; setContext("client", client);

      Wouldn't this set context to undefined initially? And reassigning a new value to client wouldn't update the value stored in the context, would it? It would only update the let client variable.

      Where does this let client actually get set to the client from async function preload? I guess I need to understand Sapper more to know how this works, but it doesn't seem like it could.

      Update: I think I found the answer (it runs before):

      https://hyp.is/3aHeJgNFEeunkCsh8FVbDQ/sapper.svelte.dev/docs/

      It lives in a context="module" script — see the tutorial — because it's not part of the component instance itself; instead, it runs before the component is created, allowing you to avoid flashes while data is fetched.

    1. Handling race conditions (e.g. an earlier fetch() finishing after a later one, thus overriding download_count with an outdated value)
  5. Aug 2020