Re: [PATCH] thread-safe handling of asynchronous events

2023-07-06 Thread felix . winkelmann
> On Wed, Jul 05, 2023 at 03:28:54PM +0200, felix.winkelm...@bevuta.com wrote: > > The first patch provides the event-queue mechanism and cleans up the > > scheduler a bit (hiding internal variables while also exposing ##sys#... > > procedures to access them). This also defines hooks that a

Re: [PATCH] thread-safe handling of asynchronous events

2023-07-06 Thread Peter Bex
On Thu, Jul 06, 2023 at 02:51:43PM +0200, felix.winkelm...@bevuta.com wrote: > That is indeed a shortcoming of the API. I must say that I'm not > too keen on the "guardian" approach, though, or your suggested hacky > workaround. There would be too many meanings attached to the > argument for the

Re: [PATCH] thread-safe handling of asynchronous events

2023-07-06 Thread Peter Bex
On Wed, Jul 05, 2023 at 03:28:54PM +0200, felix.winkelm...@bevuta.com wrote: > The first patch provides the event-queue mechanism and cleans up the > scheduler a bit (hiding internal variables while also exposing ##sys#... > procedures to access them). This also defines hooks that a threading >

Re: [PATCH] thread-safe handling of asynchronous events

2023-07-06 Thread felix . winkelmann
> Perhaps simply we can just return two values? The first a polling > procedure and the second a procedure to add new objects to the > finalizer? You can just receive the polling procedure in a > single-value context and ignore the object-adder if you don't want > to use it. That was also my

Re: [PATCH] thread-safe handling of asynchronous events

2023-07-06 Thread felix . winkelmann
> On Wed, Jul 05, 2023 at 03:28:54PM +0200, felix.winkelm...@bevuta.com wrote: > > The first patch provides the event-queue mechanism and cleans up the > > scheduler a bit (hiding internal variables while also exposing ##sys#... > > procedures to access them). This also defines hooks that a

Re: [PATCH] fix "tail?"

2023-07-06 Thread Peter Bex
On Wed, Jul 05, 2023 at 07:27:43PM +0200, felix.winkelm...@bevuta.com wrote: > Reported by "acdw": make "tail?" more robust. Also generalizes > it to accept all types of data, remove unneeded fast path expecting > proper list argument. Thanks, pushed! Cheers, Peter signature.asc Description: