Re: RFC: make _fiber_start() return a handle on the fiber


Liu, Sharron <sharron.liu@...>
 

Returning a handler maybe is good for app to invoke other fiber related APIs for operation on same fiber.

But regarding the case described below, I have question can "nano_sem_give" be used instead of requesting fiber_wakeup()? From Zephyr document I learnt both "semaphore wait" and "sleep" blocks the execution of fiber and triggers the scheduler to dequeue another executable fiber.

Thanks,
Sharron

-----Original Message-----
From: Benjamin Walsh [mailto:benjamin.walsh(a)windriver.com]
Sent: Saturday, February 20, 2016 1:17 AM
To: Nashif, Anas <anas.nashif(a)intel.com>
Cc: devel(a)lists.zephyrproject.org; Rissanen, Jukka <jukka.rissanen(a)intel.com>
Subject: [devel] Re: RFC: make _fiber_start() return a handle on the fiber

When we start a fiber via the _fiber_start() API family, we don't
get back a handle on the created fiber. The fiber identifier is
actually the start of the fiber's stack. This hasn't been a
problem until now since no API requires a handle on the fiber,
except one, fiber_delayed_start_cancel(): that API is part of a
pair, where the other API, fiber_delayed_start() starts the fiber
and returns a handle.

However, Jukka asked me an API could be created that cancels a
fiber_sleep() call, something like fiber_wakeup(). The
implementation of such an API is very simple, but it requires a
handle on the fiber we want to wake up. This in turn requires the
signature of the _fiber_start() family to return a handle to the
fiber that gets started.

The signature of _fiber_start() et al. would then change from a
void return type to a void * return type.

Objections, comments, etc ?
Sounds good, but we need to do it in away that keeps APIs
compatible I guess.
We're just returning a thread ID when we start a fiber now, you can
ignore it. I don't see an issue here...
You are right, this will not break existing code. Nevertheless, we
should track such API changes and document them in release notes.
Sure.

Join devel@lists.zephyrproject.org to automatically receive all group messages.