[feat] Option to execute jobs on the same event loop "inline"

[naz]

Problem

Executing jobs on a separate thread through worker_thread or in a separate process comes with a price of additional memory allocation and time taken to spawn up a thread/process. Because of these constraints it's sometimes more efficient to run jobs in the same event loop. For example, a job which has few non blocking (async) operations and needs to be executed on specific schedule.

Solution

Introduce an option to job configuration to execute it as an "inline" function. Proposing an option name: offloaded, which would have to be set to false to run in the same even loop.

The solution would need to look into restrictions that would come with running such functions.

@niftylettuce @shadowgate15 would love to hear your opinions on this topic and hear your thoughts about the new option naming.

[cayuu]

We ended up having to roll our own to enable something like this, for a variety of use-cases where this was the right trade off. It was also handy being able to share DB connection pool context for certain types of jobs.

[shadowgate15]

In order for it to offload it would probably make since for bree to create a dedicated worker that could then accept a message containing the path to the job and run the job. This way the main thread does not get stuck and therefore no longer processing other scheduled jobs that should be run on a separate event loop.

It probably makes sense to address #45, before trying to do this. If #45 was addressed it might resolve this issue without a specified "offload" option, since the overhead wouldn't be a problem any more.

[naz]

Hey @niftylettuce, @titanism, and @shadowgate15 is inlining jobs still something you'd be happy to have as a part of the package?

One of the usecases for such jobs is being able to have all the environment setup as the parent process has already but use same messaging, scheduling, etc. as the rest of jobs in bree. The implementation I'm thinking of is similar to one Ghost has taken through fastq - I'd aim to mostly port the functionality from Ghost's job manager into bree.

Or do you think non-worker-thread work is not something that belongs to bree?

[titanism]

New features and PR's always welcome. We don't use inline jobs because if one crashes then all crash on same process, which is why we did this with worker threads.

[naz]

Awesome, thanks @titanism. Yes, you are spot on with the downside of inline jobs. It's a trade-off a developer would need to decide on when choosing a way to run their jobs 👍