| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
As reported by clang-tidy-8.
|
|
|
|
|
| |
There is no guarantee that scheduler is alive when message
is pushed to the mailbox.
|
|
|
|
| |
Thus we enforce client to retain the returned `Scheduler` objects.
|
|
|
|
|
|
| |
The newly introduced `Scheduler::GetSequenced()` returns
sequenced schedulers from the cache limited to 10 instances,
preventing from spawning too many threads.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This commit refactors `utils::ThreadPool` into a template
`ThreadedScheduler` class and provides aux type aliases.
So that it is possible to obtain a sequenced schedule,where
all the scheduled tasks are guarantied to be executed
consequently.
The sequenced lightweight scheduler is required by both the
orchestration thread and the refactored `FileSource` implementation.
|
|
|
|
| |
So that it is possible to schedule normal `std::function` and use `mapbox::base::WeakPtr`.
|
|
|
|
|
|
|
|
|
|
| |
- Do not carry it over everywhere as parameter, it is a shared
instance anyway and the lifecycle is pretty much the app lifecycle
from the moment we instantiate a map.
- Rename to BackgroundScheduler because it is a Scheduler that will
do tasks in the background, we don't make assumptions if it is a
thread pool or a single thread.
- Most importantly, remove the dependency from `core` on `platform`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Introduce AspiringActor, EstablishedActor
This pair of objects represents the two-phase (parent-thread /
child-thread) construction that's needed to support constructing
Thread<Object> without blocking until the child thread is up and
running.
An `AspiringActor<O>` is responsible for:
- ownership of the actor's `Mailbox`
- allocating the memory for (but *not* constructing) the target object `O`
Using these two pieces--the mailbox and a stable address for `O`--an
`AspiringActor<O>` can accept messages for the target object, or provide
`ActorRef<O>`s that do so, before the object has actually been
constructed by the corresponding `EstablishedActor<O>`. (Such messages
are queued in the mailbox until after the object is constructed.)
This allows for an `AspiringActor<O>` to be created and safely used by a
thread other than the one on which the target object will (eventually)
live.
An `EstablishedActor<O>` is responsible for managing the lifetime of the
target object `O` and the open/closed state of the parent's `mailbox`.
The `O` object's lifetime is contained by that of its owning
`EstablishedActor<O>`: the `EstablishedActor` constructor executes the
`O` constructor via "placement new", constructing it at the address
provided by the parent `AspiringActor`, and the `~EstablishedActor`
destructor similarly executes the `~O` destructor (after closing the
mailbox). `EstablishedActor` should therefore live entirely on the
thread intended to own `O`.
* Remove Actor#{invoke,ask}
|
|
|
|
| |
- Adds a way to set the current scheduler on the thread to be used whenever a mailbox is created that needs to reply on this thread
|
|
|
|
|
| |
They will be needed by the DefaultFileSource, something that we
also export as public.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise, an ActorRef that's in the process of sending a message could attempt to access an invalid Scheduler reference:
Thread 1 Thread 2
--------------------------------------------------
Scheduler::Scheduler
Actor::Actor
weakMailbox.lock()
Actor::~Actor
Scheduler::~Scheduler
mailbox->push()
scheduler.schedule() 💣
|
|
|
|
| |
Map constructor takes Scheduler&, and consumers are expected to define an implementation. Therefore the interface must be public.
|
| |
|
|
|
|
|
|
|
| |
Updates mbgl::Map constructor usage everywhere
Adds NodeThreadPool implementation using AsyncQueue to call
Nan::AsyncQueueWorker from main thread
|
| |
|
| |
|
|
|