Currently we don't support migration of currently running timers. Current code
flow in __mod_timer() is:
- Find a cpu where we should migrate the timer
- Check if timer is currently running
- If yes, don't migrate.
In this process, the first step is a unnecessary activiy, if the timer is
currently
On 09/26/2012 04:00 PM, Sergey Senozhatsky wrote:
On (09/27/12 00:09), Magnus Fromreide wrote:
That they fail to throw exceptions from new is no reason to disable
set_new_handler, the newhandler is called by the runtime on out of memory
and is intended to allow the user to try fixing the issue.
On 09/28/2012 10:10 AM, Sergey Senozhatsky wrote:
On (09/28/12 09:54), Chris Ferron wrote:
[..]
Well to be fair, not that I agree any-more, but years ago it was
common practice to disable exceptions (via the compiler) for C++ in
very specialized "REAL" "Embedded Systems". This practice was
probl
Hi Thomas,
I haven't tested it much till now. I am sending this patch just to check if the
initial idea looks fine to you guys or not.
Till now, we weren't migrating a running timer because with migration
del_timer_sync() can't detect that the timer's handler yet has not finished.
Now, when can
On (09/28/12 09:54), Chris Ferron wrote:
[..]
> Well to be fair, not that I agree any-more, but years ago it was
> common practice to disable exceptions (via the compiler) for C++ in
> very specialized "REAL" "Embedded Systems". This practice was
> problematic in that you needed to have a will defi
