apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Extending apr_procattr API
Date Sat, 19 Apr 2008 13:39:05 GMT
Hi,

I wish to extend the apr_procattr APP with few additional
functions that would allow to portably pass arbitrary binary
data from parent to child process.

Here is the usage:

1. attr = apr_procattr_create()
2. apr_procattr_data_set(attr, [key,] data, size)
    ...
3. apr_proc_create(attr, ...)

In child

1. attr = apr_procattr_child_get()
2. data = apr_procattr_child_data_get(attr, index | key, &size)
    ... do something with data from parent.

How it's done:

On each platform apr_procattr_t has additional array
of {size_t, const void * } for storing data tuples or
hash table (not sure what's more feasible from the
usage PoV and persistence).

On windows in parent:
1. CreateProcess with CREATE_SUSPENDED flag
2. Obtain childs pid
3. Create named shared memory with aprchild_<child_pid>
    as name
4. Copy array to the shared memory (persist)
    { num_elements, {size, data[size] } }
5. Resume child's execution

In child:
1. calling apr_procattr_child_get() causes to open the
shared memory named aprchild_<getpid()>.
If present create array with data from shared
memory.

2. Use it (eg. duplicate sockets, pipe name, params)
    In essence for everything for which we use whatever
    IPC when we need to pass some startup data from parent
    to the child

On posix:

In parent:
Very simple ;)
after fork() we already have attr so simply create shared memory
and copy content of array to it using child's security
context.

In child:
same as in windows. Create attr and load hash table from
shared memory. The only problem here is the need for
portable naming of the shared memory (ideas?)

The call of course makes sense only for childs that
are APR aware, and it is up to the client to figure out
what to do with the data and how to interpret each
data tuple. The data for apr_procattr_data_set must be
linear (so it up to the application to construct the data
in persistable way)

Comments?

Regards
--
(TM)

Mime
View raw message