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

[Jay]

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.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 21:31:22 +1100CC: m3devel at elegosoft.comSubject: 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/20090114/60ca374b/attachment-0002.html>