Thanks Joe - that sounds like a good idea.

I also saw this today, which says that osx doesn't have support for 
thread local storage at all. Have I understood that right?:
http://dobbscodetalk.com/index.php?option=com_myblog&show=Porting-D-to-the-Mac.html&Itemid=29

Cheers,

Phil

Joe Groff wrote:
>> Hi All,
>>
>> Quick update:
>>
>> Last night I managed to get win32 factor to bootstrap and run on my
>> linux laptop using wine and mingw32 so I can now do some windows
>> portability coding. Unfortunately I'm having some problems with the
>> reentrancy code, which I guess are also problems on 'real' win32
>> platforms too.
>>
>> After some limited testing my best guess is that thread-local- 
>> storage is
>> causing problems with LoadLibrary (dlsym) loaded symbols. Internal
>> variables are fine but those externally referenced in factor code
>> indirectly using the rel-dlsym word (e.g. words in x86.factor) seem to
>> crash the vm.
> 
> At a glance it looks like the "nursery" pointer is the only thing the  
> compiler references out of the VM. You could add a VM primitive to  
> return the nursery symbol if that's the case. If I'm wrong and there  
> are other VM symbols referenced from Factor code, you could take  
> Slava's advice and roll all the global VM state into a single thread- 
> local struct variable, then add a primitive that returns a pointer to  
> that struct. You could then replace all references to VM symbols with  
> alien struct accessors.
> 
> -Joe
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Factor-talk mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/factor-talk
> 



------------------------------------------------------------------------------
_______________________________________________
Factor-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/factor-talk

Reply via email to