React switch with newly created events.

React switch with newly created events.

[Guillaume Yziquel]

Hello.

I've recently been working again of React, and I have the following 
question. Current code is below.

I'm creating an event with React.E.switch, that creates a new event 
through the schedule function, and this new events replaces the old 
event. React.E.switch is used for this replacement.

React.E.switch initial_event (React.E.map begin function () -> schedule 
(rescheduler ()) end tick)

However, it may happen (and it does happen) that as soon as this new 
React.event is created, an event is fired before the React.E.switch has 
been executed to replace the old event by the new event.

This is due to Lwt concurrency.

I therefore have two potential solutions:

-1- clutter my code with mutexes to synchronise the whole stuff, with 
the disadvantage that there is not, to my knowledge, to execute a 
function just after the React.E.switch function has effectively switched 
events.

-2- look for a way in React to do it within React only. Which would mean 
to somehow implement within React a way to switch to a newly created 
event, without race conditions.

What would you do in this context?

Here's the code:

> let reschedule ?attach:(f = begin fun x -> x end) start rescheduler =
>   (* The let define tick in E.fix define is the proper way to
>      implement recursive events. define has type React.event ->
>      (React.event * React.event) and its argument is a placeholder
>      for the event at time t-dt. *)
>   let attach initial_event =
>     let define tick =
>       (* Here is something I worry about: It is possible that the event created
>          with the schedule function is fired before it is attached to the switched
>          event, hence losing an event, and stalling the whole regular event. *)
>       let tick' = React.E.switch initial_event (React.E.map
>         begin function () -> schedule (rescheduler ()) end tick) in
>       tick', tick'
>     in f (React.E.fix define) in
>   schedule ~attach:attach start
> 
> let regular_schedule ?attach:(f = begin fun x -> x end) start period =
>   reschedule ~attach:f start (fun () -> Calendar.add (Calendar.now ()) period)

-- 
      Guillaume Yziquel
http://yziquel.homelinux.org/

Re: React switch with newly created events.

[Daniel Bünzli]

> However, it may happen (and it does happen) that as soon as this new
> React.event is created, an event is fired before the React.E.switch has been
> executed to replace the old event by the new event.

You are creating a new update cycle inside another update cycle and
this is disallowed. No primitives are allowed to update in an update
cycle (to be precise unless the primitive does not belong to the
dependency graph of the update cycle).

> -1- clutter my code with mutexes to synchronise the whole stuff, with the
> disadvantage that there is not, to my knowledge, to execute a function just
> after the React.E.switch function has effectively switched events.

I don't understand what you are saying (a word must be missing). But
yes you need to serialize the updates, see
http://erratique.ch/software/react/doc/React#update but I guess you
already know that.
.
> -2- look for a way in React to do it within React only. Which would mean to
> somehow implement within React a way to switch to a newly created event,
> without race conditions.

You can perfectly switch to a newly created event, primitive or not.
If the event is not a primitive it may even have an occurence in the
same update cycle (e.g. if the dynamic creation depends on the
updating primitive itself). However if it's a primitive event it
cannot have an occurence in the same update cycle as this would start
a new update cycle and this is disallowed.

Daniel

Re: React switch with newly created events.

[Guillaume Yziquel]

Daniel Bünzli a écrit :
>> However, it may happen (and it does happen) that as soon as this new
>> React.event is created, an event is fired before the React.E.switch has been
>> executed to replace the old event by the new event.
> 
> You are creating a new update cycle inside another update cycle and
> this is disallowed. No primitives are allowed to update in an update
> cycle (to be precise unless the primitive does not belong to the
> dependency graph of the update cycle).

No, this is not the case. There's only one update cycle. I was confused 
and sked the question too quickly. It works perfectly...

-- 
      Guillaume Yziquel
http://yziquel.homelinux.org/