[m-dev.] For review: coroutining changes

[Fergus Henderson]

On 26-Nov-1998, Thomas Charles Conway <conway at cs.mu.OZ.AU> wrote:
> On Wed, Nov 25, 1998 at 04:28:38PM EST, Fergus Henderson wrote:
> 	[forwarding function to FD_ZERO]
> > That stuff should probably go in mercury_misc.{c.h}, alongside
> > `MR_memcpy()', since it exists for very similar reasons.
> > 
> > It is also non-portable and hence should be #ifdef'd and autoconf'd.
> It is POSIX, just not ANSI.

Yes, but we have plans to port to non-POSIX systems.
In particular, Mission Critical are currently working on porting
to MSVC++ and/or mingw32 (gnu-win32 without the POSIX emulation layer)
on Windows, I believe.  We shouldn't make any changes that would make their
task harder.

> I moved the forwarding function for FD_ZERO into mercury_misc.c
> but that doesn't work, because mercury_misc.c includes mercury_regs.h.
> Unlike MR_memcpy, we can't reimplement FD_ZERO because it works on
> an abstract type.
> 
> In general it seems sensible to have a C module for stuff that has this
> kind of property - should I create one? Suggestions?

Yes, that seems like a good idea.  I suppose you could call it
`mercury_reg_workarounds.[ch]'.

BTW, I think you should report the problem with FD_ZERO as a bug to the
glibc maintainers.  Their code should work even if user code makes use
of global registers variables.  At very least they should protect
code making use of specific registers with #ifdefs so that users
can disable it by defining a macro.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh>  |   but source code lives forever"
PGP: finger fjh at 128.250.37.3        |     -- leaked Microsoft memo.