Calling fork() from JNI code

[Tomei Ningen]

What happens when I call fork() in JNI code? Will this totally break the Activity lifecycle model in Android?

Or will things just magically work?

Say I launch the browser and go to google home page. From there, I navigate to T-Mobile. So my browser history stack is [Google -> T-Mobile].

At this point, I fork() the browser process.

What I want is now the system has two browser processes running, each of them having a [Google -> T-Mobile] history stack. While I use one of these processes to browse the web, the history stack in the other process is unchanged, and I want to be able to switch between these two processes using some sort of UI.

In terms of technical difficulty (regardless of UI design), how hard is it to hack Android to produce this behavior?

Thanks

[Dianne Hackborn]

Don't do this.  Just don't.

--
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.  All such questions should be posted on public forums, where I and others can see and answer them.

[JS]

LOL, you're asking for trouble. why not start another browser
activity?

[David Turner]

fork() does not preserve threads in the child process (apart the thread that called the fork() itself).
it is very likely that the child will not run properly at all.

Also, file descriptors are duplicated, which can result in hideous corruptions problems when the two processes
try to read or write to the same database file (as an example).

You should really, really don't do that to launch a second browser :-)

[David Given]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Turner wrote:
> fork() does not preserve threads in the child process (apart the thread
> that called the fork() itself).
> it is very likely that the child will not run properly at all.

It's not just threads --- it is, for example, *undefined* whether IPC
primitives like semaphores and mutexes are shared, duplicated, or just
become invalid after a fork()! I'd upgrade your 'very likely' to an
'almost certain'...

(Cautionary tale: I spent *months* debugging a problem where one of my
apps was acting weirdly, sometimes, on some systems, none of which were
mine. I eventually figured out that I was initialising a mutex, locking
it, then calling daemon(), then using the mutex elsewhere. I'd forgotten
that daemon() calls fork behind the scenes; you call it in one process
and it returns from a different one. One this particular platform
mutexes are initialised implicitly; you initialise the structure to
zeroes, and just lock it. But when forked, they become uninitialised. So
the overall effect was that my mutex silently unlocked itself when
daemon() was called --- with hilarious results. Trust me on this; you
simply don't want to go there.)

- --
David Given
d...@cowlark.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJi78uf9E0noFvlzgRAotsAJ9ewcuEoUC5uwEMNgD5VtxkxcadaQCffa6i
9+BWwUhNG17PFOZyLDXVBZ0=
=0ZhZ
-----END PGP SIGNATURE-----