Re: New name for "AudioWorker"

Keep in mind I'm not suggesting the Worker infrastructure for EACH custom
audio processor - or even for each type instance.  There's ONE worker
thread, that all of audio runs in.

On Thu, Oct 8, 2015 at 6:17 AM, Paul Adenot <padenot@mozilla.com> wrote:

> "Not run continuously", as in, you don't decide when it runs and when it
> does not. You can't wake it up. This is not compatible with event loops as
> spec-ced today.
>
> In any case, the current worker infrastructure is way to heavy for any of
> the applications we want here.
>
> Paul.
>
>
>
>
>
> On Wed, Oct 7, 2015 at 8:34 PM, Alex Russell <slightlyoff@google.com>
> wrote:
>
>> On Wed, Oct 7, 2015 at 9:48 AM, Paul Adenot <padenot@mozilla.com> wrote:
>>
>>> On Wed, Oct 7, 2015 at 6:32 PM, Chris Wilson <cwilso@google.com> wrote:
>>>
>>>> I'm actually off-the-cuff against trying to boil the ocean of the
>>>> general pattern.  This is pretty specific - the new thing , runs *IN*
>>>> something that can be a Worker-like process, but they're expected to share
>>>> the process.  The thing you can instantiate lots of (runtime contexts?) run
>>>> inside that process.
>>>>
>>>
>>> It might look like a worker-like process, but is actually pretty
>>> different: it does not run continuously, for starters.
>>>
>>
>> We have a variant of this in both Shared Worker and Service Worker. Why
>> is this different than those?
>>
>>
>>> I was expecting we would rename AW to CustomAudioProcessor, still define
>>>> them as running inside a Worker (and define how that Worker-sharing works),
>>>> and use Worker messaging.  That seemed like the shortest path to success.
>>>>
>>>
>>> Yes, but we've clearly shown that this cannot work, because workers
>>> bring in a model and APIs that can't work for us.
>>>
>>> We have the same model than what the CSS and video folk need (something
>>> happens on some thread, we run a bit of script on this thread). We also
>>> need light input from ECMA so we don't redefine too much things. I think
>>> it's the right way to do it to avoid wasting other people's time and have
>>> solid spec and implementations.
>>>
>>> Paul.
>>>
>>>
>>>>
>>>> On Wed, Oct 7, 2015 at 9:16 AM, Hongchan Choi <hongchan@google.com>
>>>> wrote:
>>>>
>>>>> Nothing forces workers to be heavy weight, but doesn't it have the
>>>>> assumption that it runs on its own thread? What we want is to be able to
>>>>> throw JS code into VM that runs on the audio thread.
>>>>>
>>>>> Perhaps we can break that assumption, and propose a new type of Worker.
>>>>>
>>>>> On Wed, Oct 7, 2015 at 9:09 AM Alex Russell <slightlyoff@google.com>
>>>>> wrote:
>>>>>
>>>>>> Why isn't this thing a worker? What forces workers to be heavyweight?
>>>>>>
>>>>>> Also, would be good to align with the Houdini folks on this as
>>>>>> they're proposing similar things in the rendering and compositing space.
>>>>>>
>>>>>> Regards
>>>>>> On 7 Oct 2015 7:52 a.m., "Paul Adenot" <padenot@mozilla.com> wrote:
>>>>>>
>>>>>>> We need to decide for a new name for something that:
>>>>>>>
>>>>>>> - Runs off-main-thread
>>>>>>> - Has access to a very limited set of APIs
>>>>>>> - Can be instantiated a lot of times in the same document (much more
>>>>>>> than Workers can or would)
>>>>>>> - Is specialized to one domain (audio, video, etc.)
>>>>>>> - ... ?
>>>>>>>
>>>>>>> It is likely that we would be the first group to spec something like
>>>>>>> this, but it would be used by other groups (layout people, video/image
>>>>>>> processing folks, etc.). We need something that is not too tied to audio,
>>>>>>> or can be adapted. I propose "Processor", which conveys the meaning of
>>>>>>> taking something as input, applying a transformation, and outputting it.
>>>>>>> I'm very open to suggestions though, this is merely to get the ball rolling.
>>>>>>>
>>>>>>> Thoughts ?
>>>>>>> Paul.
>>>>>>>
>>>>>>
>>>>
>>>
>>
>