[M3devel] nt386gnu threads?

[Tony Hosking]

On Jan 28, 2008, at 11:19 AM, Jay wrote:

> 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... :)

Not sure: can \ be used as an escape in file names?

> 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..

I think NT386GNU always used Win32 threads.

>
>
>  - 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. Learn more.