Parallelism and task sources #202
Comments
Is there a documentation regarding to this? I heard that "Return promise and run the remaining steps in parallel" pattern is deprecated but never heard that "in parallel" itself is, that's new to me 👀 |
|
Perhaps "deprecated" is too strong a word. "Unfavored"? "overused"? "Rarely the best choice"? It seems that "in parallel" is often an under-specification because it introduces races into any algorithm steps that operate on global state, and is unnecessary in the case of steps that operate on local state in the context of a returned promise. It was applied more widely in older specs. What few specs I have written have gotten by with a parallel queue, task source, or the use of promises. In the case of the clipboard, the problem introduced by this "in parallel" is that "check clipboard read permission" should theoretically always return false, because the step Also it now occurs to me that the read() algorithm should just not reference the permission task source at all because it doesn't actually check any permission at the moment. |
This effectively gets rid of the "in parallel" part of the spec algorithms that say "create a promise, then in parallel". This parallelism isn't necessary and introduces races. See w3c/clipboard-apis#202 Example of a fixed race: the check that the renderer is focused. This check could have failed if the site lost focus very shortly after using the clipboard (albeit not a very catastrophic outcome). It also has the effect of eliminating an extra copy of clipboard data, which could save a lot of memory depending on the size of the payload. This change also introduces a task source for the clipboard as mentioned in https://www.w3.org/TR/clipboard-apis/#clipboard-task-source This task source is useful for making sure multiple clipboard operations (reading, writing to the system clipboard) are not occurring in parallel. Other steps, like when an error condition causes a promise to be rejected, need not be executed on that same task source. Note that the spec currently fails to describe many of the error conditions that Chromium implements. Also note that Chromium's implementation fails to group steps that should be part of a single operation into a single task in the queue. See crbug.com/1510722 Bug: 1510722,1501971 Change-Id: I2eb7e8ca61bd3f7f1830514c8a68b3f1ddec042a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5113849 Reviewed-by: Anupam Snigdha <[email protected]> Reviewed-by: Daniel Cheng <[email protected]> Commit-Queue: Evan Stade <[email protected]> Reviewed-by: Scott Haseley <[email protected]> Cr-Commit-Position: refs/heads/main@{#1236575}
This effectively gets rid of the "in parallel" part of the spec algorithms that say "create a promise, then in parallel". This parallelism isn't necessary and introduces races. See w3c/clipboard-apis#202 Example of a fixed race: the check that the renderer is focused. This check could have failed if the site lost focus very shortly after using the clipboard (albeit not a very catastrophic outcome). It also has the effect of eliminating an extra copy of clipboard data, which could save a lot of memory depending on the size of the payload. This change also introduces a task source for the clipboard as mentioned in https://www.w3.org/TR/clipboard-apis/#clipboard-task-source This task source is useful for making sure multiple clipboard operations (reading, writing to the system clipboard) are not occurring in parallel. Other steps, like when an error condition causes a promise to be rejected, need not be executed on that same task source. Note that the spec currently fails to describe many of the error conditions that Chromium implements. Also note that Chromium's implementation fails to group steps that should be part of a single operation into a single task in the queue. See crbug.com/1510722 Bug: 1510722,1501971 Change-Id: I2eb7e8ca61bd3f7f1830514c8a68b3f1ddec042a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5113849 Reviewed-by: Anupam Snigdha <[email protected]> Reviewed-by: Daniel Cheng <[email protected]> Commit-Queue: Evan Stade <[email protected]> Reviewed-by: Scott Haseley <[email protected]> Cr-Commit-Position: refs/heads/main@{#1236575} NOKEYCHECK=True GitOrigin-RevId: 35ff80a930b42b4aa25bf8b0e8624448c9c34f35
This effectively gets rid of the "in parallel" part of the spec algorithms that say "create a promise, then in parallel". This parallelism isn't necessary and introduces races. See w3c/clipboard-apis#202 Example of a fixed race: the check that the renderer is focused. This check could have failed if the site lost focus very shortly after using the clipboard (albeit not a very catastrophic outcome). It also has the effect of eliminating an extra copy of clipboard data, which could save a lot of memory depending on the size of the payload. This change also introduces a task source for the clipboard as mentioned in https://www.w3.org/TR/clipboard-apis/#clipboard-task-source This task source is useful for making sure multiple clipboard operations (reading, writing to the system clipboard) are not occurring in parallel. Other steps, like when an error condition causes a promise to be rejected, need not be executed on that same task source. Note that the spec currently fails to describe many of the error conditions that Chromium implements. Also note that Chromium's implementation fails to group steps that should be part of a single operation into a single task in the queue. See crbug.com/1510722 Bug: 1510722,1501971 Change-Id: I2eb7e8ca61bd3f7f1830514c8a68b3f1ddec042a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5113849 Reviewed-by: Anupam Snigdha <[email protected]> Reviewed-by: Daniel Cheng <[email protected]> Commit-Queue: Evan Stade <[email protected]> Reviewed-by: Scott Haseley <[email protected]> Cr-Commit-Position: refs/heads/main@{#1236575} CrOS-Libchrome-Original-Commit: 35ff80a930b42b4aa25bf8b0e8624448c9c34f35
A few related comments:
read()algorithm verifies permissions "in parallel", which is, AFAIU, a deprecated way to describe parallelism. Presumably this should be done on the permissions task source, so the "in parallel" should instead be a task queued on the permission task source.write()place data on the system clipboard on the clipboard task source).The text was updated successfully, but these errors were encountered: