Does NDK support multi-process?

[James SDC]

Hi,

Does anyone know if Android NDK supports multi-process, say share
memory?

I know that we can use lock from Android Java level to support multi-
thread. Rather than that, what else can we use for the multiple thread
and multiple application supports?

Many Thanks,
James.

[fadden]

Everything in libc is fair game. That includes mmap(), pthreads, and
the various Linux IPC mechanisms.

What problem are you trying to solve?

[James SDC]

Hi Fadden,

Thank you very much for your information. The problem I want to solve,
is to have a share resource in a common place, say shared code or
shared data in a shared memory, so that multiple threads and multiple
applications can use them accordingly, without interleaving problems.

The mmap() looks very close to solve my problem. However, how can I
map my data of a buffer to the memory, and how can I tell the other
application about the location of the mapped memory?


Thanks,
James.

[James SDC]

Fadden,

I have just studied the Linux IPC mechanisms. I think this is exactly
the answer for my problem. Thank you very much for your help, and the
useful information.


Best regards,
James.

[Dianne Hackborn]

Except please please please do not use fork().  Use the standard high-level facilities (via AndroidManifest.xml) for managing multiple processes.

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Anton Persson]

OK, could you please explain the problem with fork()?

[Dianne Hackborn]

The system doesn't know about that process so can't manage it.

[James SDC]

Hi Dianne,

I have tried to use shmget() and shmat() with the Android NDK 1.5_r1
package, but I got "undefined reference" with them. I tried to search
them from all *.h files of the package, but the PC could not find
them.

Do you know if Android NDK supports share memory?

Thanks,
James.

[Dianne Hackborn]

Sorry I can't help.

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[David Turner]

The SysV IPC system calls are not supported on Android. They are broken by design and lead to nasty denial-of-service

from ordinary looking applications. I have removed them explicitely. See 

More about that

On Wed, Nov 4, 2009 at 2:51 PM, James SDC <hanz...@gmail.com> wrote:

[fadden]

On Nov 4, 2:51 pm, James SDC <hanzon...@gmail.com> wrote:
> I have tried to use shmget() and shmat() with the Android NDK 1.5_r1
> package, but I got "undefined reference" with them. I tried to search
> them from all *.h files of the package, but the PC could not find
> them.

Take a look at system/core/init/property_service.c : init_workspace()
(the system properties mechanism used by getprop/setprop). It creates
a shared memory segment on top of the ashmem mechanism. Any process
with the file descriptor can mmap() it, as happens over in bionic/libc/
bionic/system_properties.c.

That uses a file descriptor inherited from init (since all processes
are children of init). If your processes are related you can use this
approach. If not, you can pass the file descriptor through a UNIX
domain socket that you create in the app's private data area.

Another option is to create a file in your app's private data area, or
on /sdcard, and just let everybody mmap() that. Much easier to code,
and you can control access to it via filesystem access permissions on /
data, but it does mean you'll be using up some amount of flash storage
(and add a little system overhead whenever dirty pages are flushed to
disk).

[James SDC]

Thanks to all of you for the useful information.

James.

[Ryosuke OISHI]

James, fadden, and Dianne,

According to docs/system/libc/SYSV-IPC.TXT ,
Android NDK doesn't support SystemV IPCs.

I understand that a process can tell anthor process
some informations such as adresses and sizes of mmap()
only using Android APIs on Java layer.

Is it correct?

On Nov 4, 8:58 am, Dianne Hackborn <hack...@android.com> wrote:
> Except please please please do not use fork().  Use the standard high-level
> facilities (via AndroidManifest.xml) for managing multiple processes.
>
>
>
>
>
> On Tue, Nov 3, 2009 at 12:58 PM, fadden <fad...@android.com> wrote:
> > On Nov 3, 12:13 pm, James SDC <hanzon...@gmail.com> wrote:
> > > Does anyone know if Android NDK supports multi-process, say share
> > > memory?
>
> > > I know that we can use lock from Android Java level to support multi-
> > > thread. Rather than that, what else can we use for the multiple thread
> > > and multiple application supports?
>
> > Everything in libc is fair game.  That includes mmap(), pthreads, and
> > the various Linux IPC mechanisms.
>
> > What problem are you trying to solve?
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "android-ndk" group.
> > To post to this group, send email to andro...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/android-ndk?hl=en.
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

[Dianne Hackborn]

You can send the file descriptor over to the other process (either with the standard linux pipe APIs, or going through Java's Binder APIs; the latter is what I would suggest, since you need to be creating the other process using the Java facilities, so you probably are doing this with a service which can provide a Binder interface allowing you to provide the fd).

hac...@android.com

[Ryosuke OISHI]

Hi James and Dianne,

Acoording to doc/system/libc/SYSTEMV-IPC.TXT, NDK doesn't support
SystemV IPCs including semaphore and shared memory.
I'd like to know how multiple NDK's processes can share any resources
without SystemV IPCs.

> --
>
> You received this message because you are subscribed to the Google Groups "android-ndk" group.
> To post to this group, send email to andro...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
>
>
>

--

Ryosuke OISHI

[Ryosuke OISHI]

James, fadden, and Dianne,

According to docs/system/libc/SYSV-IPC.TXT ,
Android NDK doesn't support SystemV IPCs.

I understand that a process can tell anthor process
some informations such as adresses and sizes of mmap()
only using Android APIs on Java layer.

Is it correct?

On Nov 4, 8:58 am, Dianne Hackborn <hack...@android.com> wrote:

> Except please please please do not use fork().  Use the standard high-level
> facilities (via AndroidManifest.xml) for managing multiple processes.
>
>
>
>
>
> On Tue, Nov 3, 2009 at 12:58 PM, fadden <fad...@android.com> wrote:
> > On Nov 3, 12:13 pm, James SDC <hanzon...@gmail.com> wrote:
> > > Does anyone know if Android NDK supports multi-process, say share
> > > memory?
>
> > > I know that we can use lock from Android Java level to support multi-
> > > thread. Rather than that, what else can we use for the multiple thread
> > > and multiple application supports?
>
> > Everything in libc is fair game.  That includes mmap(), pthreads, and
> > the various Linux IPC mechanisms.
>
> > What problem are you trying to solve?
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "android-ndk" group.
> > To post to this group, send email to andro...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/android-ndk?hl=en.
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

[David Turner]

I'm not sure I understand your question, but first there are no "NDK processes",

just normal Android VM applications that happen to use native code written with the NDK.

Now, if you want two such processes to communicate, you should use the Binder from Java.

If you absolutely want to communicate at the native level, you could try one of these methods:

- create a Unix domain socket in application A's directory, and have application B open it

  (this assumes that application B can access A's data directory, i.e. that they use a shared UID)

- create a memory-mapped file that can be opened by both A and B (same restrictions apply)

There is no native interface to the Binder provided by the NDK. I doubt there will be one any

time soon though, the current implementation is too tied to the internal platform to be exposed.