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 917486a 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.

[aadcg]

This change goes beyond the scope of the PR, so I'd kindly ask to remove it.

[jmercouris]

+1

[Ambrevar]

This PR changes thread management and one of the important features is to do it properly. This could be highlighted by the tests initially not working properly on ECL and macOS. Hence the need to restore the matrix to a wider state.

[aadcg]

It must be acknowledged that you find that an alternative CI design amounts to higher quality standards. I'd suggest having that exchange elsewhere (for instance, an issue). I consider that this PR is not the right context.

The current design of the CI was the product of thoughtful joint discussions with @jmercouris. Seeing a change of strategy without prior notice or discussion and within another context seems to lack some cordiality. I think we all have a vested interested in respecting each other's perspectives and reaching an amenable outcome for all.

[jmercouris]

@Ambrevar can you please put it in another, separate PR?

[Ambrevar]

Done in #37.

[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.