Re: [MACTCL] memory & sockets

[Daniel A. S. <st...@ic...>]

At 19:16 +0200 on 27/8/01, Mats Bengtsson wrote:

>While we are discussing memory stuffs here:
>In my QuickTime package I use NewGWorld() as follows:
>
>	err =3D NewGWorld( &newGWorldPtr, 32, &aRect, NULL, NULL, 0 );
>	if (err !=3D noErr) {
>		err =3D NewGWorld( &newGWorldPtr, 32, &aRect, NULL, 
>NULL, useTempMem );
>	}
>     if (err !=3D noErr) {
>	    panic( "Out of memory: NewGWorld failed" );
>	}
>
>Should I use useTempMem as the first option?


tclMacAlloc.c tries to make sure that there is at least TOOLBOX_SPACE 
(currently 512K) of heap space free, it would be good if your code 
could take similar precautions e.g. by implementing a similar 
strategy to what is done in tclMacAlloc.c (allocate and lock a 
purgeable handle of e.g. size 512K, then try to allocate memory the 
way you do already, then unlock the handle, next time around check if 
the handle has been purged, if yes reallocate it)

>Also, I use NewHandle to store compressed images which may take a lot
>of memory. Should I use NewHandleSys to take memory from the system heap
>instead? I'd like to make precaution from being stabbed in my back with
>memory problems.

You can do something similar to the above with NewHandle and 
TempNewHandle (NEVER use NewHandleSys, it has been deprecated for a 
long time and is dangerous) or if you don't need relocatable memory, 
just use Tcl's ckalloc and let it handle all this for you.

>
>Socket code:
>
>It is sad that the socket code is in such a terrible condition,
>so I had a look at tclMackSock.c... I wouldn't touch it with my
>bare hands, it looks very messy (probably due to the MacTCP APIs).
>So I looked at the OpenTransport docs (1.3), and it seemed fairly
>straightforward until I reached page 150 or so, where it says something
>about "deferred interrupt time" where you can't even allocate memory...
>At that point I stopped reading. :-(

:-) same problem here

>Next, looked at the Unix channel code in tclUnixChan.c where the
>tcp channel driver take up about half of that file (1000 lines readable cod=
e).
>I got the GUSI stuff from SourceForge and found out that also MacPerl
>(and MacPython) uses GUSI.
>
>Wouldn't it be an idee to just get the unix channel driver code from
>tclUnixChan.c, link it with GUSI, and make it into an extension,
>just for testing? Are there any problems with this?

I don't know about the extension approach, but it should certainly be 
possible to try to replace the mac socket code in e.g. target 
ppc=A5TestLibrary of TclLibraries.=B9 by the unix code and GUSI and see 
if it compiles and if sockets work in 'TclTest (PPC)'. Maybe you can 
give it a try?

Cheers,

Daniel
-- 
** Daniel A. Steffen          **  "And now to something completely
** Department of Mathematics  **   different"    Monty Python
** Macquarie University       ** <mailto:st...@ma...>
** NSW 2109 Australia         ** <http://www.maths.mq.edu.au/~steffen/>