[M3devel] threading on Windows?

[Jay K]

Daniel, you generally make very little sense to me. Please consider additional English training.
 
 
"Modula-3" defines and implements its own threading library, it's own I/O library, it's own traced and untraced memory allocator (traced == garbage collected), it's own GUI library (Trestle).
 
It is its own portabilty layer, akin to various other options, e.g. using pthreads and then implementing pthreads on Windows, using Tk or Qt, etc., and depending on them to be ported. etc.
Yes, I am deliberately confusing "language" and "library".
Which are people interested in? One, the other, or both?
 
 
Now, granted, we are portable between essentially only two platforms Win32/NT and "Posix", where "Posix" is defined as including pthreads and X Windows, and even in a sense gcc.
  (Even if Modula-3 predates Posix, the dependencies are pretty light, such that they have mostly always been almost consistent across the board -- open/read/write/close, socket/accept/connect/recv/send/listen, a few variations for signals).
  (Personally I would like to change the backend to generate C...)
 
 
One could "get out of this (library) business" and target another intermediate portability layer, i.e. write "bindings" for Tk, Qt, etc., and then use Modula-3 "just" as a language, and not an associated large set of libraries.
 
 
In general, it is desired for portability layers to be thin in terms of performance and possibly state.
Ideally, given the choice of writing to Win32 threads and getting the smallest fastest program that runs only on Wondows, or pthreads and getting the smallest fastest program that runs on Posix, nobody should shy away from using Modula-3 threads, since they run pretty much just as well as Win32 and pthreads. Pretty much.
Actually condition variables can't be done super well on Win32 prior to Vista, but they are done in a pretty ok way now.
Still, threads and mutexes at least are very thin layers.
 
 
Implementing threading more completely yourself, on many systems, precludes you from actually running on more than one processor.
Win7's "user mode scheduling" offers an option with more control and still the ability to run on multiple processors.
But I suspect we aren't very interested, at least not currently.
 
 
 
 - Jay
 


Date: Thu, 10 Feb 2011 23:40:48 +0000
From: dabenavidesd at yahoo.es
To: hosking at cs.purdue.edu; jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] threading on Windows?





Hi all:
is useful to say here that the compiler linker approach at some extent was done in the same way as was in Modula-3, now Open Watcom, used same runtime structure and required as far as I know no better enlightment in the original versions of it, I read it some quite time ago in its sources, hard to tell you where it was, but if OpenWatcom sold it as a Windows solution in its runtime why not in the Modula-3 one, indeed how it would be to port its linker to work for Modula-3 and tune it for the  required  works of it. Is better to adapt to a better portable (Linux, etc) solution than  to adapt to a  non-portable still solution as I believe.
Thanks in advance

--- El jue, 10/2/11, Jay K <jay.krell at cornell.edu> escribió:


De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] threading on Windows?
Para: "Tony" <hosking at cs.purdue.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 10 de febrero, 2011 17:11




Why is it better?  Because rebinding to a different function is just a matter of changing an INTERFACE in the libraries, rather than hacking the compiler.



On Feb 10, 2011, at 6:01 AM, jay.krell at cornell.edu wrote:


1. I never understood why this any better.
2. It how things are currently.
3. Why not m3cg.alloca? (but see #2)

 - Jay/iPad

 
You really think there's a way to do this w/o a special case in the compiler? I highly doubt that.
Granted, I haven't looked at it and I will spend a few minutes doing so, but again, I highly doubt this can be anything but a very special case.
Maybe runtime hooks allow for an enum comparison instead of a string comparison.
m3cg.alloca allows the most direct route w/o discovering the special case in a general purpose path.
 
 
Inlining...well, on NT, the stack pages must be touched in order.
Code that does merely: void f() { char foo[4097]; } incurs a function calls in the prolog.
The function called is _chkstk.
It is a long standing bug in the NT/x86 backend that it doesn't do this.
Given that jmpbuf is always way smaller than 4K, doing merely sub esp,Jmpbuf__size is probably reasonable.
As well, oh...well, that's not m3cg.Alloca, that's reall m3cg.AllocaJmpbufSize...which is specific enough,
that if the backend wants to know the target jmpbuf size, it can optimize slightly thereof.
We could make it be m3cg.AllocaSmallValue(name: TEXT).
I'm torn. Many many many almost identical options.
 
 
As well, Target.i3 could contain a jumpbuf size, default it to 0. If it is zero, use the code I have now.
If it isn't zero, use the old code. Something like that.
Yes, I realize there are changes in the EH code possibly implied.
 
 
Again, _chkstk has a highly custom calling convention, both its input parameter and output don't follow convention.
RTHooks makes that not a special case? I'll look later..
 
 
- Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110211/7d819671/attachment-0002.html>