[M3devel] nt386gnu threads?

Jay jayk123 at hotmail.com
Mon Jan 28 17:19:48 CET 2008


I understand how to write pthread.i3 but it is tedious and I am lazy. This idea that the headers have to be rewritten in Modula-3 bugs me. I realize it purchases my "crazy cross" but it's not the only way -- the native headers distributed to other machines could work....but then I realize it buys writing more Modula-3 and less C, and I'm not sure that's valuable. :)
 
For now I've copied/pasted bits and pieces around to get m3core.dll to build. It builds.
I believe Cygwin Pthreads are layered on Win32 threads.
I'm sure they add cost oh well.
Yes NT386GNU will use Cygwin and it'll be slow.
NT386MINGNU will use cm3cg and only build slowly.
 
It is painfully noticable how much more slowly NT386GNU m3cc builds than NT386MINGNU m3cc, presumably due to the underlying slower bash/sed/make etc.
 
All just twiddle the slashes around... I did twiddle M3Path to print like c:/cm3 and accept either input. I probably will stil make it accept either input, since from a certain point of view, that is more correct. Oh, I had treating \ and / the same on all platforms -- surely \ never occurs anyway on Unix... :)
 
The Cygwin stuff was either out of date for vtalarm, or  I was building the wrong files and thought it was broken. So I went back to pthreads. Besides, vtalarm threads put you in the shady business of creating stacks and such..
 
 - Jay



> CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] nt386gnu threads?> Date: Mon, 28 Jan 2008 11:02:25 -0500> To: jayk123 at hotmail.com> > > On Jan 28, 2008, at 6:29 AM, Jay wrote:> > > Can anyone confirm my read that PM3's NT386GNU used user/vtalarm > > threads?> > Indeed. Pthread support has only been available in CM3 since I > started on it in in 2006. Thus, unless it was using Win32 threads it > had to have been SIGVTALRM based (ie, implemented as in ThreadPosix.m3).> > > PM3 appears to have no PThread support ant its NT386GNU appears to > > have OS_TYPE=POSIX.> > Heck, even its NT386 has OS_TYPE=POSIX, but its NT386 is probably > > dead/broken.> >> > 1) I'm too lazy to tediously rewrite Cygwin's pthread.h et. al. > > into Modula-3.> > I am unfamiliar with Cygwin pthread support. Are they layered on > win32 threads? It is not terribly hard to write Upthread.i3 and > friends.> > > 2) The thread library you pick is not an independent decision.> > The Modula-3 File I/O libraries interact with the threading > > library at least a little bit.> > The POSIX file IO libraries are known to function with both > ThreadPThread and ThreadPosix (SIGVTALRM). Thus, you should be able > to use them cleanly if the Cygwin-based Modula-3 implementation takes > on a purely/mainly POSIX personality (as many of us have argued it > should!).> > > The path of less resistance seems to be user/vtalarm threads for > > now, until> > such time as Cygwin Upthread.i3 is written.> > Yes, indeed.> > > (That is, neither pthreads nor win32 satisfied my laziness; I'm > > going to try user/vtalarm threads, see how it goes; I'm sure they > > aren't very good, but...)> > Certainly, you won't get any multicore benefit with SIGVTALRM-based > threads.> 
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging. You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080128/a6ac99da/attachment-0002.html>


More information about the M3devel mailing list