Hallo devs!
In m_sched.c, line 383, there is the following declaration:
--------------8<---------8<---------- /* sys_idlehook is a hook the user can fill in to grab idle time. Return nonzero if you actually used the time; otherwise we're really really idle and will now sleep. */ int (*sys_idlehook)(void); -------8<------------8<--------------
which get's called in line 483:
--------8<---------8<-------------- /* call externally installed idle function if any. */ if (!sys_idlehook || !sys_idlehook()) { /* if even that had nothing to do, sleep. */ if (timeforward != SENDDACS_SLEPT) sys_microsleep(sys_sleepgrain); } -----------8<--------------8<------
So, I'm not really sure, how to use this callback ... If I write e.g. an external which uses this callback, how am I sure, that the specific function will be executed ? Because in an other external, thread, or whatever, I could simply assign to that callback an other function !? because there is only a callback for one function ? (or am I thinking in a wrong direction ?)
(and I didn't find an example that uses this callback ... if there is one please let me know)
Thanks, LG Georg
PS: and yes I know there are the idle callbacks in devel which do exactly this - but how to do it in the current pd ?
hi georg.
--------------8<---------8<---------- /* sys_idlehook is a hook the user can fill in to grab idle time. Return nonzero if you actually used the time; otherwise we're really really idle and will now sleep. */ int (*sys_idlehook)(void); -------8<------------8<--------------
currently, miller's pd has the feature of using 1 (one) function pointer as idle hook. you can set it and it will get called. but if you want to use it, there is _no_ way to make sure, that this idle hook is not overridden by another function, nor if it will ever be called. it gives some functionality, but it's not reliable if you would want to work with it. it will work as long as you're the only one, who is using this hook, and you only set it in one thread.
i doubt that anyone ever used it because of this and thus i removed it from devel.
the only safe way to do thread synchronisation in miller's pd is using the sys_lock() ... but locks are bad, so don't use threads :-)
cheers ... tim
Tim Blechmann wrote:
hi georg.
--------------8<---------8<---------- /* sys_idlehook is a hook the user can fill in to grab idle time. Return nonzero if you actually used the time; otherwise we're really really idle and will now sleep. */ int (*sys_idlehook)(void); -------8<------------8<--------------
currently, miller's pd has the feature of using 1 (one) function pointer as idle hook. you can set it and it will get called. but if you want to use it, there is _no_ way to make sure, that this idle hook is not overridden by another function, nor if it will ever be called. it gives some functionality, but it's not reliable if you would want to work with it. it will work as long as you're the only one, who is using this hook, and you only set it in one thread.
i doubt that anyone ever used it because of this and thus i removed it from devel.
the only safe way to do thread synchronisation in miller's pd is using the sys_lock() ... but locks are bad, so don't use threads :-)
cheers ... tim
Surely if there were a procedure in place for using the idlehook, this could be made to work: e.g. any external could check to see if idlehook was taken already. If so, copy the existing idlehook into its local space and replace the idlehook with its own. When the new idlehook is called, it should first call the old one and then its own before returning the 'or' of the two results. On deallocating an idlehook, the external's deconstructor should replace the old idlehook. The last idlehook to be removed would be replaced with NULL.
Martin
Surely if there were a procedure in place for using the idlehook, this could be made to work: e.g. any external could check to see if idlehook was taken already. If so, copy the existing idlehook into its local space and replace the idlehook with its own. When the new idlehook is called, it should first call the old one and then its own before returning the 'or' of the two results. On deallocating an idlehook, the external's deconstructor should replace the old idlehook. The last idlehook to be removed would be replaced with NULL.
right, but there are no guaranties that assure this. one badly written external could ruin the whole system.
imo, this is something, that should be done by the kernel.
t
Tim Blechmann wrote:
Surely if there were a procedure in place for using the idlehook, this could be made to work: e.g. any external could check to see if idlehook was taken already. If so, copy the existing idlehook into its local space and replace the idlehook with its own. When the new idlehook is called, it should first call the old one and then its own before returning the 'or' of the two results. On deallocating an idlehook, the external's deconstructor should replace the old idlehook. The last idlehook to be removed would be replaced with NULL.
right, but there are no guaranties that assure this. one badly written external could ruin the whole system.
imo, this is something, that should be done by the kernel.
t
Yes, there should be a function in the kernel to register a callback, and then it would manage the chaining for the externals. But since one can already register a callback with clock_new(), this is probably redundant(?).
Martin
Yes, there should be a function in the kernel to register a callback, and then it would manage the chaining for the externals. But since one can already register a callback with clock_new(), this is probably redundant(?).
it depends on what you want to do with your callbacks ... devel has the idle callbacks, that solve nearly every problem ...
t
Tim Blechmann wrote:
Yes, there should be a function in the kernel to register a callback, and then it would manage the chaining for the externals. But since one can already register a callback with clock_new(), this is probably redundant(?).
it depends on what you want to do with your callbacks ... devel has the idle callbacks, that solve nearly every problem ...
t
Oh, OK. Do they replace sys_idlehook()? Will their setup and destroy functions be exposed in m_pd.h?
Martin
it depends on what you want to do with your callbacks ... devel has the idle callbacks, that solve nearly every problem ...
Oh, OK. Do they replace sys_idlehook()? Will their setup and destroy functions be exposed in m_pd.h?
i removed sys_idlehook from devel's m_pd.h. i don't think, that anyone who wants to have a reliable external is going to use them.
t
Tim Blechmann wrote:
it depends on what you want to do with your callbacks ... devel has the idle callbacks, that solve nearly every problem ...
Oh, OK. Do they replace sys_idlehook()? Will their setup and destroy functions be exposed in m_pd.h?
i removed sys_idlehook from devel's m_pd.h. i don't think, that anyone who wants to have a reliable external is going to use them.
t
So what do you mean by 'idle callbacks'?
Martin
Hallo!
So what do you mean by 'idle callbacks'?
in pd_devel there is a (lockfree) fifo of callbacks - you can put a callback function in this fifo. in idle time the callbacks are taken from the fifo, if there is still time for it ...
LG Georg
Martin
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
Georg Holzmann -
Martin Peach -
Tim Blechmann