[M3devel] malloc/free from Modula-3?
jay.krell at cornell.edu
Tue Apr 19 08:15:49 CEST 2011
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
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.
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.
> 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:
> >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.
> > - 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the M3devel