Re: [boost] Boost.Fiber review January 6-15

Subject: Re: [boost] Boost.Fiber review January 6-15
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2014-01-09 03:06:41

2014/1/9 Agustín K-ballo Bergé <kaballo86_at_[hidden]>

> - The constructor takes a nullary function, instead of a callable and an
> arbitrary number of parameters.

will collide with the additional parameters required by fibers and not part
of boost::thread/std::thread
for arbitrary number of parameters bind() could be used

It is not clear whether Fn has to be a function object or if it can be a
> callable as with std::thread.

can be callable

> The order of parameters of the overload taking attributes does not match
> that of boost::thread.
>

the attributes control things like stack-size which is not required by
boost::thread

>
> - No notion of native_handle (this may not make sense for fibers, I
> haven't looked at the implementation).
>

native_handle in the context of thread referre to handles of the underlying
framework (for instance pthread)
for fibers not applicable

> - There is no notion of explicit operator bool in neither boost::thread
> nor std::thread.
>

add for convenience to the if a fiber instance is valid or not (== check
for not-a-fiber)

> - There is an operator < for fibers and none for id. There should be no
> relational operators for fiber, and the full set for fiber::id as well as
> hash support and ostream insertion.
>

id has 'operator<' etc.

> - Several functions take a fixed time_point type instead of a chrono one.
>

it is a typedef of chrono::steady_clock/system_clock -> otherwise all
scheduler instances would have made templates

> - There is no indication whether the futures support void (I assume they
> do) and R& (I assume they don't).

future supports future< R >, future< R & >, future< void > - the problem
was how to express it in a comfortable way in the docu

> The return type for shared_future::get is wrong.
>

OK - this is a copy-and-past error from future<>::get. I'll fix it!

> - The documentation for promise doesn't seem to support void, it is
> unclear whether they support references. Another explicit operator bool.
>

promise supports promise< R >, promise< R& >, promise< void > - suggestions
how to write the docu without repreating the interface for the
specializations?

> - I saw mentions of async in the documentation, but I couldn't find the
> actual documentation for it.

the docu about futures has a short reference to async() but I'll add a
explicit section for async() too.

> It's not clear whether deferred futures are supported, at least they
> appear not to be from future's reference.
>

not supported