"It may be that memory allocation / freeing are not thread safe, and calling GetMemInfo while another task is doing memory stuff is not safe. The module loader allocates an 'uncached' buffer to load the file, and frees it afterwards - this should probably be changed to keep the buffer for the next module load." (in response to the crashes reported in my previous post in this thread)
"Given the complexity of the GPS code, I'm not sure how safe this will be as a module - never really anticipated a module starting it's own tasks."(the dng flt module does but seems to be the only one)
I don't think there should be any inherent problem with modules starting their own tasks, as long as they ensure the module remains loaded while the tasks are running.
Quote from: reyalp on 29 / November / 2014, 18:04:47I don't think there should be any inherent problem with modules starting their own tasks, as long as they ensure the module remains loaded while the tasks are running.Struggling with how to do that so it always works. In most of the current module implementations, there is a "running" variable (semaphore/flag) used to indicate whether the module is safe to unload or not. If running is cleared just before a call to ExitTask(); there is a small window between the two instructions where the module could get unloaded prior to the task exiting. I think this sort of thing is usually handled at the OS level in most systems. CHDK hacks a loadable module format on top of the OS that the tasking mechanism in unaware of. Or did I miss something simple here? (again).
That pretty much sums it up - welcome to the house of cards
Is there a way for the task to unload itself rather than wait for the code in spytask to do it via the original routine called when the module was loaded ?
In most of the current module implementations, there is a "running" variable (semaphore/flag) used to indicate whether the module is safe to unload or not. If running is cleared just before a call to ExitTask(); there is a small window between the two instructions where the module could get unloaded prior to the task exiting.
static int unload_time=0;int _module_can_unload(){ if (running == 1) { unload_time = 0; return 0; }// running == 0 if (!unload_time) {// previous state was running, don't allow unload for 1 sec unload_time = get_tick_count() + 1000; return 0; }// has unload time passed return unload_time < get_tick_count();}
One way to deal with this would be to force some delay after the module declared itself done.
Probably more than good enough. But the "how long a delay" conversation and the "it wont' always work" have been played out thousands of times I'm sure. Unless you can disable interrupts, all of this is just hoping.
module_exit_task(int *flag) { *flag=1; ExitTask();}
Another approach would be to make sure the code that sets the final "ok to unload" flag and calls ExitTask is in the core rather than the module, something likeCode: [Select]module_exit_task(int *flag) { *flag=1; ExitTask();}
Started by pan « 1 2 » Feature Requests
Started by vine General Discussion and Assistance
Started by caladeira « 1 2 3 » DSLR Hack development
Started by rivermivida CHDK Releases
Started by geojoe Firmware Dumping
