[M3devel] eliminate Target.Global_handler_stack?

[Jay]

Target.Global_handler_stack is FALSE for targets that ever use kernel threads.Target.Global_handler_stack is TRUE for targets that never use kernel threads.
Targets that can go either way set it to FALSE.
 
When Global_handler_stack is TRUE, inline code is generated to,  I guess, manipulate a per-thread linked list of stack frames.
 
When Global_handler_stack is FALSE, function calls are generated  to do same.
 
That is, Global_handler_stack is TRUE is a little more efficient.
 
Given that Global_handler_stack is TRUE for all "recent", "active", "interesting"  targets, with the presumably temporary exception of PPC_LINUX, how about  we remove Global_handler_stack as a variable and just act as if it is always FALSE?
 
(I have some suspicion that this linked list is absent on targets with a stack walker, so it'd make no difference on them. I'll check later..NT386 ought use fs:0 but it doesn't.)
 
I figure target-specificity should be minimized.
Make it easier to bring up new targets -- not that the code isn't pretty
  well commented and easy to understand, so it's really no easier without this.
 
The counterpoints would be:  Even if it is target-specific, it does work and isn't complicated, so leave it alone.  If those old targets are alive, and lack pthreads, it is slightly faster this way.  If people want current/new targets to have a "faster" single threaded mode, this    could be part of that. Note though that single threaded apps can't/don't exist,
   unless maybe if you never heap allocate, since the heap allocator/garbage collector
   creates a thread at initialization (shouldn't it wait for a heap allocation? Maybe.
   If there really is a chance it won't occur or won't occur for a while).
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080512/2394e038/attachment-0001.html>