[M3devel] win32 AlertPause polls instead of one big wait?

[Tony Hosking]

FreeBSD pthreads has not previously been supported.  Just Linux, Solaris, OSX.

On 12 Dec 2009, at 00:37, Jay K wrote:

> 
> Randy, I was just going to ask about this..:
> 
> 
> 
> 
> 
> building with Visual C++ 2.0 (banner says copyright 1994):
> 
> Time.mo : error LNK2001: unresolved external symbol "_GetSystemTimeAsFileTime at 4"
> WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_GetIcon at 12"
> WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_LoadImageA at 28"
> WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_Remove at 8"
> WinImageList.mo : error LNK2001: unresolved external symbol "_ImageList_ReplaceIcon at 12"
> ThreadWin32C.obj : error LNK2001: unresolved external symbol "_InterlockedCompareExchange"
> ThreadWin32.mo : error LNK2001: unresolved external symbol "_InterlockedCompareExchange at 12"
> RTOS.mo : error LNK2001: unresolved external symbol "_IsDebuggerPresent at 0"
> m3core.dll : error LNK1120: 8 unresolved externals
> 
> 
> 
> building with Visual C++ 4.0 (circa 1996?):
> ThreadWin32.mo : error LNK2001: unresolved external symbol _InterlockedCompareExchange at 12
> ThreadWin32C.obj : error LNK2001: unresolved external symbol _InterlockedCompareExchange
> m3core.dll : fatal error LNK1120: 2 unresolved externals
> 
> 
> 
> building with Visual C++ 4.2 (circa 1996?):
> works
> 
> 
> 
> Which is also some significant measure of what operating systems work.
> 
> I had deleted \cm3\lib. If you build in m3-win\import-libs, then the problems drop to just InterlockedCompareExchange, and that is easily fixed. Though again it is a measure of what operating system versions will work.
> 
> 
> 
> 
> 
> I'm really undecided here. Our dependency on anything beyond Windows 95/NT 3.1, maybe even Win32s, is really slight or nonexistant. If you look at the above list for example, InterlockedCompareExchange I /just/ introduced to replace a lock, a lock that I had only introduced recently as part of removing the giant lock (the lock is much smaller). IsDebuggerPresent is really optional. GetSystemTimeAsFileTime is trivial to do without. ImageList stuff probably isn't needed -- we certainly get stuff at the wrong layer because of a certain part of our architecture. You know, normally in C / C++, there's no comctl32.dll support at any lower level, whoever needs it just #includes commctl.h. It is our "wrappers" that introduce this dependency.
> 
> The way I discover the stack boundaries might not work on Win9x/Win32s, but it might.
> 
> 
> 
> 
> 
> For testing I make sure Juno can startup several times, the system can rebuild itself, and sometimes run test p007.
> 
> If all that works, things are better than they were for a long time.
> 
> For many months Juno would sometimes hang due to a bug that affected all programs.
> 
>  Granted, we didn't necessarily ever release that bug.
> 
> In comparison the pthreads code has also had long standing problems..I think..at least on FreeBSD.
> 
> For better and for worse, these parts of the system do need work imho.
> 
> 
> 
> 
> 
> My changes are also mostly for the simpler. Of course nobody can decide what is "simple".
> 
> The change to remove the giant lock from LockMutex/UnlockMutex agrees with Birrel's paper, which only implies the lock might be there for an optimization elsewhere, an optimization that we didn't have.
> 
> Let me know of any slight or suspected problem and esp. let me run the code

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091212/6de9ef8c/attachment-0002.html>