[Ovmsdev] Event task

[Michael Balzer]

A solution for this could be to let SignalEvent() create a copy of the object pointed to, and let the event task free that after calling all listeners.

That wouldn't work for nested objects, but would be sufficient for standard event data transport.



Am 07.04.2018 um 11:51 schrieb Michael Balzer:
> Mark,
>
> event listeners currently get pointers to objects in the user data field. If we change to asynchronous execution like this, those pointers are no longer valid
> if they don't point to static objects.
>
> I'm using event data pointers for the EMCY detail data transport in my SEVCON module so would need to change that.
>
> I haven't checked if / where we currently use event data pointers in the framework.
>
> Regards,
> Michael
>
>
> Am 07.04.2018 um 11:26 schrieb Mark Webb-Johnson:
>> I’m seeing a timing/stack/mutex/whatever issue with the new 3.1 modules, regarding sd card auto-mounting at boot.
>>
>> Currently we are using a freertos timer to auto-mount this 500ms after insertion. That fires off some events (sd.inserted, sd.mounted) and I have a script on sd.mounted that does some things like turn on log file to /sd/ovms.log. That is failing (locking up SD). In general, as Michael pointed out, doing big things in freertos timers is not recommended.
>>
>> I tried a quick fix to change to use ticker.1 and housekeeping timers. But, then in ticker.1 we SignalEvent sd.inserted and sd.mounted, and that leads to a whole new set of problems (raising a signal inside a signal handler).
>>
>> Overall, it seems messy. The housekeeping task (where we like to run these things) is also very basic at the moment.
>>
>> I think the better solution maybe to remove the housekeeping task completely, and replace it with an event task reading events off a queue and firing them to all listeners. Then change SignalEvent to queue an event to the event task so that the event task fires the actual event in it’s own time and in it’s own large stack.
>>
>> The slight change here is that we would still guarantee in-order delivery of events raised, but the caller of SignalEvent would immediately get back control (even if the signal had not been dispatched to all listeners yet).
>>
>> OK? Any better suggestions?
>>
>> Regards, Mark
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26