Hi Peter & Ben,
toggle quoted messageShow quoted text
I am seeing couple of issues when trying to wake up a fiber.
1) if my fiber tries to to wake up itself (yes, there was a bug in my
program), there seems to be weird issues (hangs). This could be just
symptoms of 2)
2) after making sure that I am not trying to wake the running fiber, I
am seeing weird issues. After running several rounds of sleeps and
wakes, the OS just hangs when calling fiber_sleep(). I wonder how to
debug this, any suggestions?
On Mon, 2016-02-22 at 18:07 +0000, Mitsis, Peter wrote:
For what it is worth, I am currently tackling this item.
From: Jukka Rissanen [mailto:jukka.rissanen(a)linux.intel.com]
Sent: February-22-16 2:01 AM
To: Walsh, Benjamin
Subject: [devel] Re: Re: RFC: make _fiber_start() return a handle
On Fri, 2016-02-19 at 10:36 -0500, Benjamin Walsh wrote:
I am a bit busy right now so I am fine if you do it.
Looks like it. You want to do the implementation yourself Jukka ?
When we start a fiber via the _fiber_start() API family, weNo comments -> no objects -> perhaps we can continue with this
get back a handle on the created fiber. The fiber identifier
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_delayed_start_cancel(): that API is part of a pair,
the other API, fiber_delayed_start() starts the fiber and
However, Jukka asked me an API could be created that cancels
fiber_sleep() call, something like fiber_wakeup(). The
implementation of such an API is very simple, but it requires
handle on the fiber we want to wake up. This in turn requires
signature of the _fiber_start() family to return a handle to
fiber that gets started.
The signature of _fiber_start() et al. would then change from
void return type to a void * return type.
Objections, comments, etc ?