[M3devel] how to switch between user and kernel threads..

[Tony Hosking]

Please leave it the way it is as an install-time option.  -DNOPTHREAD  
enables user threads.

On 16 Jan 2009, at 20:28, Jay wrote:

> I was able to easily build this alternate library, just by creating  
> one small m3makefile and optionally editing one other very little.
> I wasn't able to find a way to get it used, other than maybe  
> shipping it on top of the "real" m3core.
> A compiler hack that knows to replace package "m3core" with  
> "m3coreuserthreads" may be appropriate.
>  I can look into that.
> But I still don't know why not function pointers.
> Plenty else to do in the meantime (Cygwin/pthreads, portability, a  
> bunch of ports..).
>
>  - Jay
>
>
>
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] how to switch between user and kernel threads..
> Date: Thu, 15 Jan 2009 04:15:43 +0000
>
> That would't affected here.
>   All the calls within ThreadPThread to within ThreadPThread would  
> remain direct and inlinable.
>   They would be to the "ThreadPThread" interface, and not the  
> "Thread" interface, would be my intent.
>
> How about across modules?
>   I expect any call from outside ThreadPThread to within  
> ThreadPThread to never be inlined, at least not when dynamic linking  
> and with static linking (or within the package/library) not unless  
> there is "whole program optimization" aka "link time code  
> generation" with static linking, which does exist out there.
>
>  - Jay
>
>
>
>
>
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Thu, 15 Jan 2009 14:18:16 +1100
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] how to switch between user and kernel threads..
>
> We do get inlining within modules by virtue of the gcc-backend at -O3.
>
>
> On 15 Jan 2009, at 14:03, Jay wrote:
>
> The installer?
> I thought the granularity was at the time of linking an executable.
> I personally thought a command line parameter would be reasonable.
>
>
> Why not function pointers?
> It is a simple straightforward method to implement.
> It should add one instruction per call.
> It does reduce inlinability but I'm sure we aren't getting any such  
> such inlinability anyway.
> Dynamic linking already kills inlinability, as does separate  
> compilation of modules in most systems.
>
>
> I'm not sure how the types work out in such a scheme, but probably  
> assuming Thread.T is already a reference type, it can become ADDRESS  
> and then loopholed to ThreadPosix.T or ThreadPThread.T.
>
>
> Function pointers are also the easiest method to build. I'm not sure  
> what the others are.
> I can try making m3-libs/m3coreuserthreads that contains only  
> m3makefiles.
> Probably it can say:
> LibraryName = "m3coreuserthreads"
> include_dir("../m3core/m3makefile")
>
>
> and m3core/m3makefile can say
> if not defined("LibraryName")
>   LibraryName = "m3core"
> end
> Library(LibraryName)
>
>
> If that works, not bad.
>
>
> And then cm3 or the config file can translate m3core to  
> m3coreuserthreads at some point.
>
>
>  - Jay
>
>
>
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Thu, 15 Jan 2009 11:31:17 +1100
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] how to switch between user and kernel threads..
>
>
> No function pointers please.  Let the installer decide whether to  
> use native or user threads.
>
> On 15 Jan 2009, at 08:30, Jay wrote:
>
> I'll wait.
> So, build two different m3core.lib/a/so/dylib?
> m3core and m3coreuserthreads
>
> Compile both thread directories, if the platform supports it, and
> call quake make_lib twice with slightly different parameters?
> An m3core specific hack in the config file or cm3?
> Easy enough in the config file.
> Very m3core specific.
> I suppose you could argue that quake isn't a generic build system,
> but it is Modula-3's build system, and that m3core is really special.
>
> The result btw, would likely be no change at all to any *.i3 or *.m3  
> file.
>
> I still think function pointers are the way to go.
> Even with function pointers, the changes to *.i3 and *.m3 would be  
> very minor.
> Just the export list would vary.
> And new *.i3 files introduced.
>
>  - Jay
>
>
>
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Wed, 14 Jan 2009 21:31:22 +1100
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] how to switch between user and kernel threads..
>
> I don't want dynamic switching.  A link-time switch is just fine.
>
> Also, please don't go messing about with this right now -- I have  
> changes pending for the threads system that will be harder to  
> integrate if you change with it further.
>
> On 14 Jan 2009, at 20:14, Jay wrote:
>
> Are people really against using function pointers for this?
> Either changing the interface to have function pointer variables  
> (I'm not sure Modula-3 allows this, but in C you can fairly  
> transparently replace functions with function pointers; client code  
> just keeps working; it breaks down in C++ with overloading), or  
> having a set of functions that just call/jump through function  
> pointers? There would be no if, no conditional branches.
>
> Dynamic linking on Windows always goes through function pointers  
> already.
>  So while yes it adds another instruction, it is already never  
> getting inlined.
> Don't other platforms do that too?
> Or they patch every call site?
>
> I'm not sure otherwise of a simple method.
> Easiest might be to have a parallel directory structure to m3core,  
> with just m3core files.
> That would wastefully rebuild all of m3core a second time, for just  
> a small amount of variation.
>
> I think function pointers are the way to go here.
>
>  - Jay
>
>
>
>
>
>
>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090117/71baa4b1/attachment-0002.html>