On 23 April 2015 at 13:54, Ola Liljedahl <ola.liljed...@linaro.org> wrote:
> On 23 April 2015 at 19:34, Mike Holmes <mike.hol...@linaro.org> wrote: > >> >> >> On 23 April 2015 at 13:13, Ola Liljedahl <ola.liljed...@linaro.org> >> wrote: >> >>> On 23 April 2015 at 12:14, Taras Kondratiuk <taras.kondrat...@linaro.org >>> > wrote: >>> >>>> On 04/22/2015 09:21 PM, Mike Holmes wrote: >>>> >>>>> We have mentioned EOs in only one place and not defined them any where >>>>> in the API doc >>>>> >>>>> /** >>>>> * Set queue context >>>>> * >>>>> * Its the responsability of the interface user to make sure >>>>> * queue context allocation is done in an area reachable for >>>>> * all EOs accessing the context >>>>> >>>> Even if we avoid using the term EO (Execution Object) as Taras suggests >>> (and I agree), the description above is not very clear (understatement). >>> What is probably meant is that it is the responsibility of the user to >>> ensure that the queue context is accessible by all threads that attempt to >>> access it. As an example, if using the ODP (multi)process model, queue >>> contexts should be allocated from ODP shared memory (including pools using >>> shared memory) and not from some per-process allocator (e.g. malloc). >>> >>> >> Ola you have made the mistake of appearing knowledgeable ;) >> > Don't confuse appearance with substance. > > >> I may quote you in a patch to fix this documentation. >> However in your description you also use the term thread and process >> which are in my mind equally bad terms to EO but in this case they mean >> something to Linux rather than Open Event Machine. >> > I don't agree. Pretty much no-one will know about EO's but most > programmers know about threads and their understanding will be pretty close > to what we mean. A thread means a thread of execution. It may or may not > have its own process (which provides address space, resource ownership etc). > > >> >> I am being pedantic to try to get clarity but should the terminology be:- >> >> It is the responsibility of the user to ensure that the queue context is >> accessible by all odp_tasks that attempt to access it. >> As an example, if using the multi odp_task model, queue contexts should >> be allocated from ODP shared memory (including pools using shared memory) >> and not from some per odp_task allocator (e.g. malloc). >> > I think odp_task is a poor choice. A task is doing something specific > work, each task has a specific purpose. ODP is much closer to a worker > thread model where threads are interchangeable (like worker bees). > > I think we should stay with "thread". I actually don't understand why you > are having a problem with it. > Only clarity, unless the topic is provoked we all assume we are in agreement on terminology. > >> >> >> >>> >>> * >>>>> * @param queue Queue handle >>>>> * @param context Address to the queue context >>>>> * >>>>> * @retval 0 on success >>>>> * @retval <0 on failure >>>>> */ >>>>> int odp_queue_set_context(odp_queue_t queue, void *context); >>>>> >>>>> Should we add a Glossary and define odp_workers and execution objects >>>>> etc? >>>>> >>>>> Should we fix this instance to just say "all threads accessing the >>>>> content" becasue we already use the term "thread" extensively in the >>>>> API >>>>> docs ? >>>>> >>>>> Thread feels very Linux specific and we dont really mean a thread since >>>>> it could be a process even for Linux. >>>>> >>>> >>>> Execution Object has different meaning in Open Event Machine framework. >>>> We should avoid using Execution Object name for ODP workers. >>>> >>>> _______________________________________________ >>>> lng-odp mailing list >>>> lng-odp@lists.linaro.org >>>> https://lists.linaro.org/mailman/listinfo/lng-odp >>>> >>> >>> >> >> >> -- >> Mike Holmes >> Technical Manager - Linaro Networking Group >> Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs >> >> >> > -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
