<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>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. :)<BR>
<BR>
For now I've copied/pasted bits and pieces around to get m3core.dll to build. It builds.<BR>
I believe Cygwin Pthreads are layered on Win32 threads.<BR>
I'm sure they add cost oh well.<BR>
Yes NT386GNU will use Cygwin and it'll be slow.<BR>
NT386MINGNU will use cm3cg and only build slowly.<BR>
<BR>
It is painfully noticable how much more slowly NT386GNU m3cc builds than NT386MINGNU m3cc, presumably due to the underlying slower bash/sed/make etc.<BR>
<BR>
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... :)<BR>
<BR>
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..<BR>
<BR>
- Jay<BR><BR>
<HR id=stopSpelling>
<BR>
> CC: m3devel@elegosoft.com<BR>> From: hosking@cs.purdue.edu<BR>> Subject: Re: [M3devel] nt386gnu threads?<BR>> Date: Mon, 28 Jan 2008 11:02:25 -0500<BR>> To: jayk123@hotmail.com<BR>> <BR>> <BR>> On Jan 28, 2008, at 6:29 AM, Jay wrote:<BR>> <BR>> > Can anyone confirm my read that PM3's NT386GNU used user/vtalarm <BR>> > threads?<BR>> <BR>> Indeed. Pthread support has only been available in CM3 since I <BR>> started on it in in 2006. Thus, unless it was using Win32 threads it <BR>> had to have been SIGVTALRM based (ie, implemented as in ThreadPosix.m3).<BR>> <BR>> > PM3 appears to have no PThread support ant its NT386GNU appears to <BR>> > have OS_TYPE=POSIX.<BR>> > Heck, even its NT386 has OS_TYPE=POSIX, but its NT386 is probably <BR>> > dead/broken.<BR>> ><BR>> > 1) I'm too lazy to tediously rewrite Cygwin's pthread.h et. al. <BR>> > into Modula-3.<BR>> <BR>> I am unfamiliar with Cygwin pthread support. Are they layered on <BR>> win32 threads? It is not terribly hard to write Upthread.i3 and <BR>> friends.<BR>> <BR>> > 2) The thread library you pick is not an independent decision.<BR>> > The Modula-3 File I/O libraries interact with the threading <BR>> > library at least a little bit.<BR>> <BR>> The POSIX file IO libraries are known to function with both <BR>> ThreadPThread and ThreadPosix (SIGVTALRM). Thus, you should be able <BR>> to use them cleanly if the Cygwin-based Modula-3 implementation takes <BR>> on a purely/mainly POSIX personality (as many of us have argued it <BR>> should!).<BR>> <BR>> > The path of less resistance seems to be user/vtalarm threads for <BR>> > now, until<BR>> > such time as Cygwin Upthread.i3 is written.<BR>> <BR>> Yes, indeed.<BR>> <BR>> > (That is, neither pthreads nor win32 satisfied my laziness; I'm <BR>> > going to try user/vtalarm threads, see how it goes; I'm sure they <BR>> > aren't very good, but...)<BR>> <BR>> Certainly, you won't get any multicore benefit with SIGVTALRM-based <BR>> threads.<BR>> <BR><BR><br /><hr />Helping your favorite cause is as easy as instant messaging. You IM, we give. <a href='http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join' target='_new'>Learn more.</a></body>
</html>