We should adopt a more neutral term for what we're currently calling threads. The term "task" was suggested. An ODP task can be instantiated as any type of execution object supported by the platform such as a thread, process, fiber, etc. Since ODP itself does not specify the memory model used by tasks this leave it up to the implementation to provide memory sharing or isolation as needed.
On Wed, Apr 22, 2015 at 1:21 PM, Mike Holmes <[email protected]> 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 > * > * @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. > > -- > 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 > >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
