{"action":"created","issue":{"url":"https://api.github.com/repos/vapoursynth/vapoursynth/issues/324","repository_url":"https://api.github.com/repos/vapoursynth/vapoursynth","labels_url":"https://api.github.com/repos/vapoursynth/vapoursynth/issues/324/labels{/name}","comments_url":"https://api.github.com/repos/vapoursynth/vapoursynth/issues/324/comments","events_url":"https://api.github.com/repos/vapoursynth/vapoursynth/issues/324/events","html_url":"https://github.com/vapoursynth/vapoursynth/issues/324","id":243885614,"number":324,"title":"Introduce wait-state for filters","user":{"login":"stuxcrystal","id":2260352,"avatar_url":"https://avatars3.githubusercontent.com/u/2260352?v=4","gravatar_id":"","url":"https://api.github.com/users/stuxcrystal","html_url":"https://github.com/stuxcrystal","followers_url":"https://api.github.com/users/stuxcrystal/followers","following_url":"https://api.github.com/users/stuxcrystal/following{/other_user}","gists_url":"https://api.github.com/users/stuxcrystal/gists{/gist_id}","starred_url":"https://api.github.com/users/stuxcrystal/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/stuxcrystal/subscriptions","organizations_url":"https://api.github.com/users/stuxcrystal/orgs","repos_url":"https://api.github.com/users/stuxcrystal/repos","events_url":"https://api.github.com/users/stuxcrystal/events{/privacy}","received_events_url":"https://api.github.com/users/stuxcrystal/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2017-07-19T00:00:18Z","updated_at":"2017-12-21T18:05:18Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"This is just an idea. I will not take it personally if it is rejected. Discussion on this proposal is encouraged.\r\n\r\n# Explanation\r\nIn essence, we allow the filter to signal that it is waiting for an external event and that the core can nowuse the worker to process other frames.\r\n\r\n# Proposed API\r\n\r\nA simple way to implement this is via a similar method to `requestFrameFilter`. It can be called from the getFrame-function of the filter to signal that the frame will enter a wait-state after exiting the function. The core will return a pointer to a handle-object that can be used to identify which filter to wake up again. I will call this function \"setFrameWaiting()\". On failure, this function should return `NULL`.\r\n\r\nWaking up a filter will require another new API-function. I will call this function `notifyFrame`. It takes a single argument; the pointer to the handle that has been returned. It will return nonzero value on failure.\r\n\r\nAfter notify frame is called, the core will schedule the getFrame-call with a new ActivationReason `arNotified`.\r\n\r\nNote that the filter may still receive frames commisioned by calls to `requestFrameFilter()`. However my proposal would forbid calling `setFrameWaiting()` while the filter is in the state \"sleeping\".\r\n\r\nShould the frame be notified while a getFrame-call to the same instance is currently being executed, the core will wait for the previous getFrame call to finish before invoking it again with arFilterNotified.\r\n\r\n## Thread Safety\r\n`notifyFrame` need to be thread safe.\r\n\r\n## API Additions\r\n* `void *setFrameWaiting(VSFrameContext *frameCtx)`\r\n* `int notifyFrame(void *handle)`\r\n* `arNotified`\r\n\r\n## Overview:\r\n\r\n    core                          frame      \r\n     |\r\n     | = getFrame(arInitial) =======> | \r\n     | <===== setFrameWaiting() ===== | \r\n     | -------------- void *handle- > |\r\n     |                                |\r\n     .                                .\r\n     .                                .\r\n     .                                .                  external Thread\r\n     |                                |                         |\r\n     | <=== notifyFrame(handle) =============================== |\r\n     | -------------------------------------------------------> |\r\n     |                                |                         |\r\n     | = getFrame(arFrameNotified) => |                         |\r\n     | <- frame --------------------- |                         |\r\n     |                                |                         |\r\n\r\n# Use-Cases\r\n\r\n1. Implementation of I/O-operations. I/O-operations usuall don't require CPU. Therefore the core may use the resources more efficiently if it could schedule another frame while I/O-operations are in process.\r\n   An example implementation would look like this: The `getFrame`-method may call `setFrameWaiting` and passing the returned handle to another thread. When the operation completes this thread will call `notifyFrame` with the handle passed to the thread.\r\n2. This model can be easily used to interoperate with other concurrency models.\r\n"},"comment":{"url":"https://api.github.com/repos/vapoursynth/vapoursynth/issues/comments/353417783","html_url":"https://github.com/vapoursynth/vapoursynth/issues/324#issuecomment-353417783","issue_url":"https://api.github.com/repos/vapoursynth/vapoursynth/issues/324","id":353417783,"user":{"login":"HuBandiT","id":10346452,"avatar_url":"https://avatars3.githubusercontent.com/u/10346452?v=4","gravatar_id":"","url":"https://api.github.com/users/HuBandiT","html_url":"https://github.com/HuBandiT","followers_url":"https://api.github.com/users/HuBandiT/followers","following_url":"https://api.github.com/users/HuBandiT/following{/other_user}","gists_url":"https://api.github.com/users/HuBandiT/gists{/gist_id}","starred_url":"https://api.github.com/users/HuBandiT/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/HuBandiT/subscriptions","organizations_url":"https://api.github.com/users/HuBandiT/orgs","repos_url":"https://api.github.com/users/HuBandiT/repos","events_url":"https://api.github.com/users/HuBandiT/events{/privacy}","received_events_url":"https://api.github.com/users/HuBandiT/received_events","type":"User","site_admin":false},"created_at":"2017-12-21T18:05:18Z","updated_at":"2017-12-21T18:05:18Z","author_association":"NONE","body":"> Should the frame be notified while a getFrame-call to the same instance is currently being executed, the core will wait for the previous getFrame call to finish before invoking it again with arFilterNotified.\r\n\r\nThink about filters that able to dispatch work that can be parallelized per `arFrameReady`, as well as dispatch/wait when all frames are ready `arAllFramesReady`. Example: each frame needs to be dispatched to GPU for preprocessing individually, and when all frames completed preprocessing, the computation of the final result from the preprocessed frames needs to be dispatched to the GPU, which will need one final round of GPU/waiting as well)."}}
{"actor":{"display_login":"HuBandiT"}}