Re: malloc() in Dllist
От | Karel Zak |
---|---|
Тема | Re: malloc() in Dllist |
Дата | |
Msg-id | Pine.LNX.3.96.1000522105455.24257A-100000@ara.zf.jcu.cz обсуждение исходный текст |
Ответ на | Re: malloc() in Dllist (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Fri, 19 May 2000, Tom Lane wrote: > Karel Zak <zakkr@zf.jcu.cz> writes: > > I'm total confuse. I continue in query cache implementation and I want use > > Dllist routines, but what I see --- it hardly use malloc/free. Why? With > > this is a Dllist usage _very_ limited... (the catcache works with malloc? > > --- hmm interesting) > > I think the reason Dllist still uses malloc directly is that the > selfsame code is used by libpq, and there's no palloc in the frontend > environment. This is pretty ugly of course. It would probably be Yes, I know about Dllist in the frontend, but more nice is use '#if' if anyone want share some code between backend-frontend. > better to give libpq its own copy of the routines (I don't think it But keep up two copy is more exigent. > needs 'em all anyway, nor ought to be polluting application namespace > with global symbols that don't start with "pq") and then the backend's > version could use palloc. But we'd have to look at all the callers to > be sure they have current memory context set to an appropriate thing. > > > Tom, assume you with some 'malloc_based_context' in your memory-management > > proposal? > > It can't be *directly* malloc based if we want to ensure that pfree() > works regardless of context type. We need that header with the > back-link to the context to be there always. We could have a context I said it bad. I also mean one-chunk-one-malloc with correct chunk header. We already discussed about back-link in chunk header. I understand you. > type where each chunk is always a separate malloc request, and palloc > is just a thin wrapper that adds the chunk header ... but I'm not sure > what for ... IMHO this is correct and rightdown solution. We have system malloc in: bootstrap/bootstrap.c, catalog/heap.c, commands/sequence.c, executor/spi.c, lib/dllist.c,gram.c / scan.c,port/dynloader/aix.c,port/dynloader/nextstep.c,regex/engine.c,regex/regcomp.c,storage/buffer/localbuf.c,storage/file/fd.c,tcop/postgres.c,tioga/Varray.c,tioga/tgRecipe.c,utils/fmgr/dfmgr.c,utils/cache/inval.c,utils/error/elog.c,utils/init/findbe.c,utils/init/miscinit.c ... it is long list :-( Spit it to more memory contexts will better. I not sure if all these routines really need directly malloc. IMHO it probably need some persistent contexts, and a one-chunk-one-malloc context very probably not will need often (or never). All these are possible implement via standard block-based contexts, but with more separete contexts. It is good described in your proposal. A context for elog, parser, ... etc. In will in 7.2 ? :-) Karel
В списке pgsql-hackers по дате отправления: