Re: [linux-audio-dev] Shared memory?

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

Subject: Re: [linux-audio-dev] Shared memory?
From: Juhana Sadeharju (kouhia_AT_nic.funet.fi)
Date: Fri Jul 04 2003 - 16:46:25 EEST


>From: Ralfs Kurmis <kurmisk_AT_inbox.lv>
>
>Try out this example
>Split it in seperate files
>( Needs x )

Hello. Thanks for the example, but I see some problems there:
if the second process does not find the segment given by the key,
you example makes two distinct segments. That is what happen with
me. Because I don't have IPC_CREAT in the second process, my
program simply fails instead of creating second segment.

I got it working otherway, but there are severe problems.
In client, I simply skipped the shmget() and queried
immediately the segment with shmat() with the mid value
printed by the server.

The example mailed here used shmget() with IPC_CREAT.
When I used IPC_CREAT for both server and client, as I expected,
I got two separate shared memories. In fact, as I make the shared
memory in shmserver which is run first, the shmclient should not use
IPC_CREAT at all.

It works, but while the server seems to fill the shared memory
with increasing integer numbers, the client behaves strangely.
I have this code in shmclient now:

  k = -1;
  for (;;) {
    if (k != nums[1]) {
      k = nums[1];
      fprintf(stderr,"%i\n",k);
    }
    // sleep(1);
    // fprintf(stderr,"ggggg\n");
  }

What should it do? It should ideally print the increasing numbers:
5435, 5436, 5437, etc. With sleep(1) it prints a new value once per
second. However, without sleep(1), it prints only one number and then
does not print anything anymore. It looks like Linux does not update
the shared memory, why?

When the "ggggg" is printed (without sleep), the shmclient prints only
one number and repeatedly the "ggggg". Why the shared memory is not
updated in this? I remember I had a similar problem with old XWave
software at 1998 with much earlier kernel version (now I have 2.4.18 of
RedHat 7.3).

This looks serious problem. It may be that nobody has noticed
it because either one uses sleep() or read()/write() in an
audio system. That is, your software may work, but the problem
may degrage the performance (as it certainly did freeze the
printing in my shmclient). Perhaps the problem may cause an audio
engine never work as fully as possible.

If you get the shmclient work while the sleep(1) is commented out,
please let me know :-)

http://www.funet.fi/~kouhia/shmserver.tar.gz

Best regards,
 
Juhana


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

This archive was generated by hypermail 2b28 : Fri Jul 04 2003 - 16:59:27 EEST