These 2 libs look similiar, but there are some big differences. boost-fiber uses M:1 scheduling, it uses a single threaded scheduler to run multiple fibers within one thread. Pros: Most synchronizations between native threads can be avoided as it's single threaded. You can use native TLS in fibers, which is more efficient than the implementations in Boost.Thread and boost.green_thread. Cons: Although you can create multiple threads to run multiple sets of fibers, each set of fibers are seperated, you need additional efforts to migrate a fiber from a thread to another(work-stealing), also TLS needs to be avoided in this case. Even with work stealing enabled, multiple fiber groups are often run into imbalance, because work stealing is not automatic in boost-fiber. boost.green_thread uses M:N scheduling, it schedules a group of green threads across multiple native threads. Pros: boost.green_thread uses ASIO io_service for scheduling, seamlessly cooperate with ASIO. Load is balanced across all native threads in a scheduler, server side programs can utilize multi CPU cores more efficiently. Cons: Multiple native worker threads need synchronization to schedule green threads Scheduling is more complex than boost-fiber, makes a scheduler with only one worker thread runs slightly slower than boost-fiber. Cannot use native TLS as green threads may migrate between native threads. Both libraries have their own pros and cons, and fit in different scenarios, my opinion, boost.green_thread is better for server side programs as it can utilize multi cores easily. Regards, Chen Xu On 2015-08-12 15:08:23 +0000, Klaim - Joël Lamotte said:

On 12 August 2015 at 16:20, Xu Chen wrote:

...

Just cleanup some codes I wrote before, there is a M:N green threading library built on top of Boost.Thread and Boost.Coroutine, conceptually it works like goroutines in Go and (once existed) green threads in Rust.

With some refinements, it now supports all C++11/14 threading standard, along with some extensions exist in Boost.Thread such as thread_group and chainable futures.

It can be integrated with Boost.ASIO, all ASIO async functions can be used as sync ones in green threads, similar to Boost.ASIO/Boost.Coroutine integration.

Also it has some facilities to communicate with foreign threads, can by used to integrate with external libs such as database drivers.

The code can be found at https://github.com/windoze/boost.green_thread

I don't know much about boostbook tools so the documents are kind of crippled, but I'll improve it if needed.

Regards, Chen Xu

I am not an expert in the domain but am I correct that you are proposing similar functionality to Boost.Fiber? ( https://github.com/olk/boost-fiber )

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Yes, green thread is some kind of wrapper of a ASIO strand. The point is, Boost.Asio and Boost.Coroutine strand do not have any synchronization mechanism. For example, a web server uses MySQL, in order to use database connection pool, you need to pause a strand when no spare DB connection available, and resume it when some other strand release a connection, a lot of code needed to do it correctly and you cannot just block worker thread as this will decrease performance significantly. By wrapping all these codes into standard compliant synchronization primitives, you can write program just like you are using normal threads, except they are scheduled by green_thread/io_service, no native worker threads get blocked when a green thread is waiting on things like mutex. Rust used to support green thread, showed how it can simplify server side programming. Also there is another project, Vibe.d written in D (http://vibed.org), has same design. Regards, Chen Xu On 2015-08-12 23:47:08 +0000, Gavin Lambert said:

On 13/08/2015 04:58, Chen Xu wrote:

...

boost.green_thread uses M:N scheduling, it schedules a group of green threads across multiple native threads. Pros: boost.green_thread uses ASIO io_service for scheduling, seamlessly cooperate with ASIO. Load is balanced across all native threads in a scheduler, server side programs can utilize multi CPU cores more efficiently. Cons: Multiple native worker threads need synchronization to schedule green threads Scheduling is more complex than boost-fiber, makes a scheduler with only one worker thread runs slightly slower than boost-fiber. Cannot use native TLS as green threads may migrate between native threads.

Can you explain how this is different from giving a single Boost.Asio io_service multiple worker threads, and just queuing work/operations to the io_service (possibly via strands)?

The description above makes it sound like a "green thread" is identical to a strand.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost