[M3commit] CVS Update: cm3

[Tony Hosking]

ThreadF is still safe for the world.  Any module that imports ThreadF  
for the purposes of using MyHeapState is going to need to be unsafe  
anyway, so forcing it to cast (unsafe anyway) is no big deal.     
MyHeapState is used only by the allocator.  To be perfectly honest, I  
would have no problem making ThreadF UNSAFE since it has so much  
dangerous stuff in it.  But leaving it safe keeps it they way it has  
always been.

On 8 Sep 2009, at 12:02, Jay K wrote:

> Really? Isn't it considerably safer to have a function declaration  
> list the actual type instead of requiring all the callers to cast?
> I left ThreadF safe and I think I left it all much better than this.
> Safety is not a boolean. I'd much rather have a lot of UNTRACED REFs  
> to specific types than a bunch of ADDRESSes.
>
>  - Jay
>
>
> > Date: Tue, 8 Sep 2009 17:16:19 +0000
> > To: m3commit at elegosoft.com
> > From: hosking at elego.de
> > Subject: [M3commit] CVS Update: cm3
> >
> > CVSROOT:	/usr/cvs
> > Changes by:	hosking at birch.	09/09/08 17:16:19
> >
> > Modified files:
> > cm3/m3-libs/m3core/src/runtime/common/: RTAllocator.m3
> > cm3/m3-libs/m3core/src/thread/Common/: m3makefile
> > cm3/m3-libs/m3core/src/thread/POSIX/: ThreadF.i3 ThreadPosix.m3
> > cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadF.i3
> > ThreadPThread.m3
> > cm3/m3-libs/m3core/src/thread/WIN32/: ThreadF.i3
> > ThreadInternal.i3
> > ThreadWin32.m3
> >
> > Log message:
> > Forgot to propagate safety fix for MyHeapState to WIN32 and POSIX.  
> Fixed now, which allows me
> > to undo Jay's unfortunate bandaid. ThreadF is safe as god intended.
> >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20090908/0bc5b62b/attachment-0002.html>