[M3devel] eliminate Target.Global_handler_stack?

[Tony Hosking]

On May 12, 2008, at 7:35 PM, Jay wrote:

> 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?

Don't you mean "false" for all current targets (i.e., using threads)?

> (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.)

Indeed, the list is absent on such targets.

> 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.

I have no  objection.

> 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).

When does the GC currently create a thread?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080512/8039d99b/attachment-0002.html>