Re: [linux-audio-dev] shared memory problems

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] shared memory problems
From: Richard Guenther (rguenth_AT_tat.physik.uni-tuebingen.de)
Date: Sun Nov 11 2001 - 19:10:09 EET


On Sun, 11 Nov 2001, Paul Davis wrote:

> and its done. the following hack satisfies this quite easily (given
> what we know about the kernel's mapping of tasks):
>
> static char *top_end_of_unmapped_memory = (char *) (1048576 * 1536); /* 1.5GB */
> static char *low_end_of_unmapped_memory = (char *) (1048576 * 1024); /* 1GB */
>
> static char *
> fixed_shmat (int shmid, char *shmaddr, int shmflg, size_t size)
> {
> char *addr;
> char *attempt;
>
> if (shmaddr != 0) {
> return shmat (shmid, shmaddr, shmflg);
> }
>
> attempt = (char *) (top_end_of_unmapped_memory - size);
>
> while (attempt > low_end_of_unmapped_memory) {
> if ((addr = (char *) shmat (shmid, attempt, shmflg|SHM_RND)) != (char *) -1) {
> top_end_of_unmapped_memory = addr;
> return addr;
> }
> attempt -= size;
> }
        ^^^^^^^^^^^^
which will unmap stuff already mapped at the regions you test (no?).

> return (char *) -1;
> }

> >of another way at the moment). Also segment:offset addressing is not
> >that difficult, if you design the data in shm to avoid having pointers
> >in the first place (i.e. use arrays + indexes rather than linked lists,
> >etc.) - also a macro for "dereferencing" hides the complexity.
>
> good food for thought. right now, i'm trying to get stuff checked into
> CVS for JACK and putting a rudimentary framework for the website. once
> that's done, you can check out the code and fix it for me, right? :)))

Of course - I was on the way to ask you for write permissions anyway, so
I can fix things as I try to do JACK for GLAME. Perhaps set up a rule for
hacking, so other than bugfixes go to personal branches which get merged
by some special person (you?).

> i wish there was a way force certain things to happen when a process
> dies on SIGKILL, though. we can't call shmctl(id,IPC_RMID) on shm
> segments until we know that no more clients will attempt to connect -
> i.e. the server is exiting (because a "marked-destroyed" segment
> cannot be accessed by a new task). thus, i defer this via
> on_exit(). alas, these are not called if it dies with SIGKILL, and we
> end up with "persistent" shm segments. sigh. at least i can handle all
> other signals properly.

Well, its easy to do this. Just have the server do a fork() early at
startup time, have the new process be the server and the parent just
waiting on the server and doing necessary cleanup. Just like X does
with Xwrapper.

> btw, i have JACK running with maarten's rudimentary FLTK client,
> rythmnlab and the prototypical simple JACK client now. lots of things
> to work on, but its starting to feel very nice.

Nice :)

Richard.

--
Richard Guenther <richard.guenther_AT_student.uni-tuebingen.de>
PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57
WWW: http://www.anatom.uni-tuebingen.de/~richi/


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Nov 11 2001 - 19:05:54 EET