[M3devel] malloc/free from Modula-3?

[Jay K]

Here is where malloc/calloc/free are handled,
in a new, somewhat redundant way, that reduces/eliminates the burden at higher levels:


jbook2:src jay$ pwd
/dev2/cm3/m3-libs/m3core/src
jbook2:src jay$ edit C/Common/CstdlibC.c


M3WRAP_NO_SWITCHING(void*, Cstdlib__malloc, malloc, (WORD_T a), (a))
M3WRAP_NO_SWITCHING(void*, Cstdlib__calloc, calloc, (WORD_T a, WORD_T b), (a, b))
M3WRAP_RETURN_VOID_NO_SWITCHING(Cstdlib__free, free, (void* a), (a))


Now, if you have other C code that is calling malloc/free, you
still need to disable switching around that.


Perhaps all calls to <*extern*> functions should disable/enableswitching.
Perhaps.
The real answer is though, make sure pthreads and Win32 threads work,
and then don't do much to make user threads faster or easier to maintain.


see m3core/src/m3core.h for definitions of those macros.
They should be pretty clear.
If not, run the C preprocessor over those files and look at the results.


--
The traditional correct thing is to wrap Cstdlib.malloc/Cstdlib.free whereever they are called.
But I kept finding this missing, got fed up with it, fixed it at a lower level.
Is that bad? Maybe. Maybe not.
--
I wouldn't argue against wrapping all <*extern*> calls with disable/enableswitching.
Given that you have to recompile everything to switch between user threads and kernel threads anyway,
the compiler could insert these calls only for user threads, perhaps.


 - Jay

> To: jay.krell at cornell.edu
> Date: Mon, 18 Apr 2011 19:27:04 -0700
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] malloc/free from Modula-3?
> 
> Jay K writes:
> >--_f28739e3-2465-450f-b041-5795980d5bfe_
> >Content-Type: text/plain; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> >
> >And "yes" you need to disable switching around free=2C the same as malloc. =
> >And calloc. And realloc.
> >The disable switching *might* be at a lower level than you realize=2C so *m=
> >ight* not be missing.
> >That is=2C it might be in our C wrappers. I can check later.
> >=20
> > - Jay
> 
> Well in that case someone should remove the
> SchedulerPosix.DisableSwitching (etc) from around the mallocs.
> 
> Or are you telling me that perhaps free() is wrapped but malloc() isn't?
> That would be... confusing.
> 
>      Mika
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110419/c0c1997c/attachment-0002.html>