[M3commit] CVS Update: cm3

[Jay]

We didn't really decide.
You insisted on no function pointers. I did nothing.
As long as userthreads not working anyway, moot.
 
 
I think the below is close to what you want, though I think
in reality we should probably have
m3-libs/m3coreuserthreads
 
m3-libs/m3coreuserthreads/src/m3makefile
  USER_THREADS = TRUE or whatever
  include(../../m3core/m3makefile)
 
 always building two .so files.
And then maybe have a quake directive that replaces m3core with m3coreuserthreads, and implies build_standalone, or something. Though that won't quite work I think, I'll see.
 
But I still suspect one .so with both implementations is reasonable.
Switchable with a command line option @M3userthreads, and a quake directive to alter the default (and offer @M3kernelthreads, we, well..cygwin for example could offer @M3win32threads and @M3pthreads, so maybe rename @M3kernelthreads to @M3pthreads).
 
There is a certain level of inlining that I think should never be expected.
Stuff that is dynamic linking should have not implementation details leaked across the dynamic link boundary. (For some definition of "implementation detail" though.. struct sizes do leak for example). If you are willing to dynamic link usually, then is it really interesting to have static linking be slightly faster?
I'm not sure.
 
Therefore, point being -- dynamic linking implies there is already a presence of function pointers (since dynamic linked function calls are always somehow indirect) and a lack of inlining. You might as well then have function pointers immediately on the "landing" site of the dynamically linked function calls that switch between userthreads and kernelthreads.
 
 
Could be that there is an option to build more optimally where userthread option is omitted and kernelthreads unconditionally used -- that would be used currently for instance on Linux where userthreads don't work (though that might be fixed), and also on Win32 where user threads never worked and nobody asked for them (though they are fixable there -- fibers).
 
 
I realize maybe there is a strong counteropinion, like, whatever inefficiences are implied by dynamic linking are to be "fought" against with aggressive/creative/even fragile optimization techniques.
 

 - Jay




----------------------------------------
> From: hosking at cs.purdue.edu
> To: jkrell at elego.de
> Date: Wed, 29 Apr 2009 07:46:48 +1000
> CC: m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
>
> Huh? I thought we decided against this...
>
> On 28 Apr 2009, at 16:23, Jay Krell wrote:
>
>> CVSROOT: /usr/cvs
>> Changes by: jkrell at birch. 09/04/28 16:23:39
>>
>> Modified files:
>> cm3/m3-libs/m3core/src/: m3makefile
>>
>> Log message:
>> put userthreads in m3coreuserthreads.so (even if this is the only
>> thread implementation for the platform)
>> This isn't likely the right long term solution, there seems to be an
>> interface incompatibility between the two (I /really/ think IF user
>> threads are to exist, they should be in the same .so and switch
>> function pointers during initialization...)
>