writeBuffe
Jul 19, 2023[Serializable] interface SharedValueTable { undefined insert([EnforceRange] unsigned long long key, any value); // value must be serializable any get([EnforceRange] unsigned long long key); undefined remove([EnforceRange] unsigned long long key); }; TODO write more Keeping track of some use cases, and random thoughts
Nov 18, 2022Issue: https://github.com/gpuweb/gpuweb/issues/3250 Proposal written and proposed by Kai, based on in-depth discussion with editors (Brandon/Myles/Kai) and more input from Brandon. Previous drafts Premises It should be possible for multiple "components" using the same device on the same thread to have different error scope state. It's okay if each component can't device.destroy() independently.
Nov 8, 2022Proposed by editors (Myles/Brandon/Kai), and written by Brandon, with edits from Kai. An ongoing concern about use of error scopes is that they may require that operations within the scope finish in-order. At this time, it's unclear if that may prevent certain classes of optimization, such as moving pipeline creation to a separate thread. (See #2119 for prior conversation on that point.) After some discussion the editors feel that in-order resolution is not a requirement for error scopes. This document outline the reasons why, and how we feel error scopes should operate. Proposal The proposal is to remove all constraints on the ordering of the resolution of promises from popErrorScope(), relative to one another and to other promises in the API. This allows implementations use a strict ordering, resolve strictly as early as possible, or anything else. The general behavior that we would expect from an error scope is:
Jul 26, 2022or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up