On 23 April 2015 at 19:34, Mike Holmes <[email protected]> wrote:
> > > On 23 April 2015 at 13:13, Ola Liljedahl <[email protected]> wrote: > >> On 23 April 2015 at 12:14, Taras Kondratiuk <[email protected]> >> 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. > > > >> >> * >>>> * @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 >>> [email protected] >>> 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 > > >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
