Re: [gtk-list] Re: glib memory management?
- From: Drazen Kacar <dave srce hr>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: glib memory management?
- Date: Tue, 20 Apr 1999 23:09:52 +0200
Erik Mouw wrote:
> I don't know about a way to manage a bunch of assigned memory, but I like
That would be memory gained with mmap() call. mmap("/dev/zero") or
a variation, since mmap() is not completely portable.
> the idea of having a memory manager for shared memory. There are however a
> couple of problems to solve:
>
> - Locking in the memory manager: the idea of a shared memory segment is
> that it is shared between processes (sic). If one of them allocates a
> piece of memory in the segment, others shouldn't be able to do the same,
> so you need some kind of locking, like SYSV IPC semaphore sets.
I had a master-slave project in mind, so there would be only one
process which allocates memory. Others would have read-only access.
But, in the general case, you're quite right. There could be some
perverse system with spinlock and yield(), but that's completely
unportable. So the semaphores are the only safe enough bet.
> - If the heap in the shared memory segment is corrupted and the memory
> manager crashes, the lock is not released and all other processes hang,
> so you must have some way to timeout and solve the problems.
Depends on your system. If you happen to have sem_open() and friends,
it can be done automagically when the last process exits. If you don't
have POSIX.1b, tough luck.
--
.-. .-. Life is a sexually transmitted disease.
(_ \ / _)
| dave@srce.hr
| dave@fly.cc.fer.hr
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]