Is pkg_malloc some sort of memory management thing? I mean, do I have to clean up, or does something come in and clean up behind me?
Is there a parent/child memory mallocator available? It would make freeing easier. A single free of the parent rather than keeping track myself.
I just don't want to be the source of a memory leak.
---greg
At 02:08 AM 3/1/2003, Greg Fausak wrote:
Is pkg_malloc some sort of memory management thing? I mean, do I have to clean up, or does something come in and clean up behind me?
It is our own malloc libary. Use malloc to allocate dynamic memory and free to give it away then.
We are using it rather than stdlib malloc because it has some convenient debugging features, can be very fast, and can be used with shmem too.
Is there a parent/child memory mallocator available? It would make freeing easier. A single free of the parent rather than keeping track myself.
We do everything manually. It takes more core but is self-rewarding in terms of speed and clarity.
If you are worried about leaks, turn on the debugging version (you need to set the proper defs in Makefile.defs) -- after termination, ser will print all unreleased fragments.
-jiri
Jiri,
I have a postgres module stumbling along. It actually was a lot more work than I thought it would be. However, it is much less work than it could have been...the layering is very nice in SER.
One thing I found difficult (probably because I'm getting older and can't program like I used to) is keeping track of memory. I've written too much java, and before that my partner wrote a memory allocation routines that I have used over the years. I have discussed it with him (Andy Fullford) and he said he would donate these routines to your project if you deem it appropriate. Basically, they allow parent/child memory relationships. When the parent is freed, all of the children are freed. Here is the manual page:
http://dubious.august.com/man/libaug/aug_alloc.htmm
Anyway, there are a couple of issues I have hit with the Postgres module and database. First, the column 'user' won't work in postgres, as it is a reserved word. So, I went with 'user_id'. This involved changing many other programs in different modules.
Second, I won't be able to completely test the module. I have tested it with my ser.cfg file, which just does subscriber and location table updates. There are a bunch of other tables used by other modules that I haven't tested because I don't use them and don't know how.
Third, I haven't worked in a public project before. Obviously handing off the postgres module directory will be easy, but the tiny changes for 'user' to 'user_id' in the many other files in other modules, how do I forward those changes, or do you even want them?
Fourth, there are other files that are related to the new database module that need to be written. For instance, serctl is wrapped up in mysql, and there is the database creation script itself. I will write these postgres based files, but at a slower pace over the next month. If true database portability is desired, then serctl needs an abstraction layer that isn't there now. Also, the database creation gear can be written in xml, but that complexity probably isn't warranted. I simply hacked my postgres database creation.
---greg
-----Original Message----- From: serusers-admin@lists.iptel.org [mailto:serusers-admin@lists.iptel.org] On Behalf Of Jiri Kuthan Sent: Saturday, March 01, 2003 10:37 AM To: Greg Fausak; serusers@lists.iptel.org Subject: Re: [Serusers] Pkg_malloc
At 02:08 AM 3/1/2003, Greg Fausak wrote:
Is pkg_malloc some sort of memory management thing? I mean, do I have to clean up, or does something come in and clean up behind me?
It is our own malloc libary. Use malloc to allocate dynamic memory and free to give it away then.
We are using it rather than stdlib malloc because it has some convenient debugging features, can be very fast, and can be used with shmem too.
Is there a parent/child memory mallocator available? It would make freeing easier. A single free of the parent rather than keeping track myself.
We do everything manually. It takes more core but is self-rewarding in terms of speed and clarity.
If you are worried about leaks, turn on the debugging version (you need to set the proper defs in Makefile.defs) -- after termination, ser will print all unreleased fragments.
-jiri
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Greg,
thank you very much. Quick comments follow inline.
At 08:12 PM 3/1/2003, Greg Fausak wrote:
One thing I found difficult (probably because I'm getting older and can't program like I used to) is keeping track of memory. I've written too much java, and before that my partner wrote a memory allocation routines that I have used over the years. I have discussed it with him (Andy Fullford) and he said he would donate these routines to your project if you deem it appropriate. Basically, they allow parent/child
Thank you -- it looks like a very convenient feature. I need to chat with our malloc owner on that. I suspect that changing ser to this library now would be very difficult.
Anyway, there are a couple of issues I have hit with the Postgres module and database. First, the column 'user' won't work in postgres, as it is a reserved word. So, I went with 'user_id'. This involved changing many other programs in different modules.
I guess that's just about changing the default column name, isn't it? If that's all, we should go for that in the upcoming release.
Second, I won't be able to completely test the module. I have tested it with my ser.cfg file, which just does subscriber and location table updates. There are a bunch of other tables used by other modules that I haven't tested because I don't use them and don't know how.
We will need to spread the testing load accross module owners. I fear that will not happen before the upcoming release.
Third, I haven't worked in a public project before. Obviously handing off the postgres module directory will be easy, but the tiny changes for 'user' to 'user_id' in the many other files in other modules, how do I forward those changes, or do you even want them?
Submit your patches, we will review them.
Fourth, there are other files that are related to the new database module that need to be written. For instance, serctl is wrapped up in mysql, and there is the database creation script itself. I will write these postgres based files, but at a slower pace over the next month.
Getting these sripts postgress-friendly would be a great help. At the moment, the best person to do that is probably you because the next most related person is myself and my latency is now growing terribly.
-Jiri
-
Greg Fausak -
Jiri Kuthan