lohnn/integral_isolates

Dart package making isolates easy

Integral Isolates

Monorepo for integral_isolates and libraries using it to make Isolates easier for developers.

Melos is used for managing the monorepo. To get started, make sure melos is installed on your machine and run

$ melos bootstrap

Packages can be found in the packages folder, each including their own README.md file.

integral_isolates's Issues

[BUG] use_isolate does not dispose the isolate when done

Describe the bug
_IsolateHookState and _IsolateHookState<Q, R> (normal and tailored) hook states does not dispose the isolate once it is done with it, leading the isolate to leak and live longer than intended.

[FEATURE REQUEST] use_isolate packe to support streams

Stream response has been added to integral_isolates, but not yet to use_isolate package.

Some exploration might be needed to come up with a scalable solution that works for use_isolate package.

This applies to both useIsolate and useTailoredIsolate hooks.

[FEATURE REQUEST] Add isolate pools (thread pools)

Is your feature request related to a problem? Please describe.
Currently integral_isolates only supports creating isolates manually, one at the time. If a developer was to increase the workload, by wanting to run more smaller jobs in parallell, or run different types of jobs from the same isolate, the back pressure strategy will not understand which jobs are connected to which intention. The work will also be quite slow, as they all share the same isolate.

Describe the solution you'd like
I'd like to investigate if we could implement an isolate pool to be able to spread the workload out.

Additional context
We will need to investigate and explore a few things:

• How do we decide how many isolates should be available in the pool?
  • Should the user/developer decide how many should be available?
    • Is there a global preference to set this?
    • Should the pool be local to just one instance of StatefulIsolate?
  • Should we automatically create threads when needed?
    • What is the upper limit of threads?
      • Maybe we peek at the CPU and create threads for best performance depending on physical threads?
• Should responses await each other to always return in the same order as the jobs that are added or should we let responses be out of order?
  • Maybe we could use tags as a way to set order?
• How to handle back pressure? Could we somehow piggyback on the queue, to decide when to run the BackPressureStrategy?

Maybe not needed?

integral_isolates/packages/integral_isolates/lib/src/integral_isolates.dart

Line 109 in 6abe351

_isolateToMainPort = _isolateToMainPort;

[FEATURE REQUEST] Plugin support

Is your feature request related to a problem? Please describe.
Trying to call a plugin within a spawn isolate fails. This limits use cases for this package.

Describe the solution you'd like
Since 13937 it's possible to pass a root token and call BackgroundIsolateBinaryMessenger.ensureInitialized within the isolate. But it only works for some plugins (those that do dart -> platform messenging, but not platform -> dart messenging). Hopefully this package can do the necessary plumbing so that it works whatever the plugin.

Describe alternatives you've considered
flutter_isolate is another package trying to make isolates nicer, and it supports plugins, but it has its own issues and limitations.

[Feature Request] Ability to run an Stream inside an isolate and communicate with a callback

My use case: I have an Isar database running on isolate (this isolate never ends, it starts with the app).

Problem is: Isar have a query watcher that results in a Stream of some type. But I can't return Streams from isolates nor pass callbacks to it, because they are in separate memory space.

So, it would be nice if this could be implemented:

abstract class Repository {
  const Repository();

  static final _isolated = Isolated(backpressureStrategy: NoBackPressureStrategy(), autoInit: true);

  static Stream<int> _staticStreamCallback(String someParameter) async* {
    yield someParameter.length;
  }

  Future<Stream<String>> listenToIsolate(String someParameter) async {
    return _isolated.isolateStream<int>(_staticStreamCallback, someParameter);
  }
}

isolateStream<T> would create a StreamController<T>, then run the user code stream (my _staticStreamCallback), piping each yield to the outside world.

This would allow us to run a Stream method in an isolate, where each yield would send the response to the SendPort, thus, reaching the main thread stream.

[DOCS] Add/improve documentation for the monorepo README

The root/monorepo README could use some new makeup.

• I would love to see direct links to the packages, with more information regarding what they are and what they do.
• A link to packages that use any of these ones, such as flame_isolate would also be nice.
• Some more information regarding how to get started
  • With melos
  • With contributing

[FEATURE REQUEST] Extension function on Stream

Is your feature request related to a problem? Please describe.
Now that we have added isolate stream functionality I want to make it easier to run functions in an isolate when building up a call chain for a stream.

Describe the solution you'd like
An extension function on Stream that allows for mapping a value asynchronously by running the function in an isolate.
Example: Stream.isolateMap(Function) // running in an isolate

Additional context
Questions that needs to be answered for implementation of this:

• What isolate should the function be run in? (Maybe from the new isolate pool, or a way to select which pool from #25?)

[DOCS] Improve documentation

We need a more exhaustive documentation, such as looking through the generated dart doc to make sure it is excellent.

But also, more importantly improve the README to have more examples, a few chapters and more explanations.

[FEATURE REQUEST] mixin on StatefulWidget

It would be nice to be able to piggy back on the lifecycle of a StatefulWidget's state for handling the StatefulIsolate, like SingleTickerProviderStateMixin.

Describe the solution you'd like
Attaching a mixin on your StatefulWidget's state that creates and holds an Isolate and exposes it for running work on the isolate.
This mixin would handle lifecycle piggybacking on the State's initState and dispose functions.

Additional context
Naming is hard, the names I have come up with so far are probably not good for different reasons.

• Reusing the name StatefulIsolate will probably end up in confusion, if even possible to implement.
• Just use Isolate would look nice (class _MyWidgetState extends StatefulWidget<MyWidget> with Isolate) but would clash with the Isolate class from Dart.

[FEATURE REQUEST] Allow sending Streams and Futures as input to Isolate

Is your feature request related to a problem? Please describe.
It is now impossible to send Futures and Streams as input to a StatefulIsolate, allowing this would greatly increase usability.

Describe the solution you'd like
StatefulIsolate should be able to handle such cases and send the items one by one to the isolate with a protocol specifically for supporting this use case. (Basically same as for Isolate -> Main, but the other way).

The backpressure strategy should consider a full stream as one input and not handle the stream as individual items/jobs.

Describe alternatives you've considered
The workaround is to await the value/values and send them manually, but that might yield unexpected results depending on backpressure strategy.

[FEATURE REQUEST] LOGO!

We need at least an MVP logo for 1.0 milestone. I'm open for ideas but will try to figure something out.

Preferably a vector image and not too detailed.

[CHORE] Update to Dart 3

Let's update the codebase to use Dart 3.

New language features that should be added:
In the cases where applicable, annotations such as @internal should be replaced with the new capability controls.
The ifs that are trying to be exhaustive could probably be replaced with the new switch for exhaustive pattern matching.

If there is more new nice features that would help us, then we should definitely add them too.