Lparallel overhaul 2

[Ambrevar]

Fixes #2 and supersedes #16, without input buffering.

I plan to add input buffering later (based on #16's work, or not).

This switches the whole thread management / concurrency logic from Calispel to Lparallel.

• It simplifies the code a lot (about 100 lines less!).
• It also makes it way less prone to race conditions, and much easier to debug.
• Also less risk of dangling threads.
• It works on ECL.
• Update notifications now happen via hooks.

To do:

• [ ] Update notifications are still awkward to use. See 917486af926d0abdc77bffa7f1ed0f9a0d1dc66e tests. They are not functional (the source object may be updated in parallel of the hook execution), and the hook may be run 2 or 3 times during each input update, which is counter-intuitive. I suggest to use 2 hooks:
  • One that is run in parallel at the very end.
  • Another one that is run like now, but in sync, thus guaranteeing the state of the source.
• [ ] Once the above is fixed, update the README to mention the API breakages (e.g. with result, notifications, extra elements in attributes).

Thoughts?

[aadcg]

• It works on ECL.

This is a non-goal in my view, but a nice to have nonetheless.

Thoughts?

Sounds like a good plan. If I understood correctly, you're not request a review yet.

[jmercouris]

Hello Pierre, a very welcome PR. I see many improvements. I am always glad to strip more dependencies from our tree.

One thing I am not understanding is the choice for a kernel per source, can you explain how/why?

Lastly, I wouldn't worry too much about breaking changes/dependents. How many people are using this library? We could query Quicklisp, and if nobody is using this library, then we needn't be strict about versioning information in my opinion.

[jmercouris]

I also don't understand the purpose of notifications/hooks. Are they so that you can know when a particular source is done loading without blocking? Is it some sort of CSP code?

[Ambrevar]

One thing I am not understanding is the choice for a kernel per source, can you explain how/why?

Quite simply: if two prompts are run in parallel (e.g. nested prompts), you want the computations to happen in parallel, i.e. you don't want a prompt to block another. Lastly, killing a kernel is a relatively clean and effective way to collect all its threads, and we can only do this if we have one kernel per prompt.

Lastly, I wouldn't worry too much about breaking changes/dependents.

It only costs a version bump and a short listing of the changes in the README. We do this for all our libraries and it's good practice, even to ourselves to remember the changes in the future.

I also don't understand the purpose of notifications/hooks. Are they so that you can know when a particular source is done loading without blocking? Is it some sort of CSP code?

Hooks are not CSP, they are just like Emacs hooks. The purpose is indeed to notify the caller when the source has changed. In practice, this is how Nyxt knows when to redraw.