Comments (8)
Because you did not mention the code lines I assume you refer to the implementation of yield_completion::wait().
The fiber calling this function locks the mutex (that protects variable completed_) and the suspends if the work was not completed yet.
Please note how the fiber is suspended: fibers::context::active()->suspend( lk);
The lock is released after this fiber has been suspended.
from fiber.
exactly, however, when suspend returns, it does not reaquire the lock, which is needed for safety
from fiber.
Why should it acquire the lock again - the variable isn't required to protected again.
from fiber.
I'll try to make it as clear as I can.
The thread that calls fibers::context::active()->set_ready( ctx_)
does so while holding the lock.
The thread that created the lock then resumes. Note that the notifying thread might still hold the lock. It might have been suspended from execution by the OS or whatever.
The resumed thread that created the lock continues and destroys the mutex.
The notifying thread never releases the lock, yet it is destroyed.
I assumed that on return of fibers::context::active()->suspend( lk)
, lk would own the mutex, but it is not the case.
this might explain what im saying.
https://gist.github.com/thadeuluiz/d1d15d25d7875f1eab2089fedd707580
from fiber.
Can confirm this is an issue in yield_handler_base::operator()(error_code)
when a different thread resumes the fibre than the one waiting on it (ASAN complains about a bad read when releasing lk
, since the resumed fibre may have already destroyed the lock).
I assumed that on return of fibers::context::active()->suspend( lk), lk would own the mutex, but it is not the case.
I also assumed this, and am surprised it's not the case (especially when this function is not documented). The current fix we're trying over the weekend is to add lk.lock();
at detail/yield.hpp:50
.
from fiber.
fibers::context is not part of public the public API, it should not be used by the users.
keep in mind that the asio binding is an example - especially some support is required by the asio library (see #102).
I'm focused on other parts of the library - so I've no time to take care for the asio binding.
from fiber.
Yeah, we're running asio and the fibers in different threads to avoid the main-loop annoyance / integrate better with existing code.
It seems weird that yield
is example code, but relies on internal APIs. Would we be better off writing something analogous to the 'use_future' in asio, returning a fiber future if we want less risk of interface breakage?
from fiber.
The problem is not related to the lock - the problem is that yield_completion is shared between async_result and yield_handler. It should go out of scope if the last reference (yield_handler or async_result) goes out of scope. Using an intrusive poitner should fix the issue.
from fiber.
Related Issues (20)
- Boost.fiber incompatible with C++20 HOT 1
- Boost.Fiber header compile fails with GCC Compile option -Werror=conversion
- Maybe a semaphore should be added HOT 1
- segment fault when closed buffered_channel on destructor
- build failed with cxxflags -D BOOST_FIBERS_NO_ATOMICS (version 1.80.0)
- Warning/error about unreferenced parameter in context.cpp HOT 2
- std::aligned_storage raises deprecation warning with the latest gcc 13 and C++23 (to be released in about 1 month and a half) HOT 2
- Boost fiber's demo run error when open AddressSanitizer by use Visual Studio HOT 1
- Build script relies on third party to import Context before Fiber
- Weird behavior with custom `algorithm_with_properties<>`
- Memory leak exists when setting custom scheduler algorithm in use_scheduling_algorithm function? HOT 1
- fiber::sleepfor stop updating when system clock moves backwards
- Launching fiber on a different thread HOT 3
- Could not link fiber 1.84.0 as shared library on Windows 10 HOT 4
- Mixing `fiber::mutex` and normal threads HOT 1
- Modular Boost C++ Libraries Request
- use it in qt
- Weird infinite loop when cv.notify_all() HOT 3
- no way to calculate hash of `fiber::id`
- Explicit context switch of fibers
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fiber.