new IPC mechanism ideas

new IPC mechanism ideas

[Rajeev Bector]

We are planning to develop a new
IPC mechanism based on shared
memory. The memory is allocated by
a device driver in the kernel
and mapped to various processes
read only. Processes talk to the
driver to write to the memory
but they can directly read the
memory (so its a 1-copy IPC
mechanism). 

We also want to make this IPC
mechanism persistent across
application restarts. So that
if an application crashes, when
it comes back up, it can remap
to its old queues and get its
messages. 

Does anyone have experiences building
such a mechanism ? Any pointers to
reading material would be really
appreciated ? 

Please cc replies to rajeev_bector@yahoo.com

Thanks !

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Re: new IPC mechanism ideas

[H. Peter Anvin]

Followup to:  <20010711014918.76554.qmail@web14404.mail.yahoo.com>
By author:    Rajeev Bector <rajeev_bector@yahoo.com>
In newsgroup: linux.dev.kernel
> 
> We are planning to develop a new IPC mechanism based on shared
> memory. The memory is allocated by a device driver in the kernel and
> mapped to various processes read only. Processes talk to the driver
> to write to the memory but they can directly read the memory (so its
> a 1-copy IPC mechanism).
> 
> We also want to make this IPC mechanism persistent across
> application restarts. So that if an application crashes, when it
> comes back up, it can remap to its old queues and get its messages.
> 
> Does anyone have experiences building such a mechanism ? Any
> pointers to reading material would be really appreciated ?
> 

Why not just use mmap() on a file?  That way you can even make it
zero-copy.  Otherwise, mmap() readonly in all but one process ("the
driver").

Nothing needed in the kernel that isn't already there...

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: new IPC mechanism ideas

[Rajeev Bector]

Thanks for your comment, Peter.
The problem with using a "driver"
process is that now you need
another mechanism to communicate
with that driver - either
message queues or shared
memory or something.

Thanks,
Rajeev


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Re: new IPC mechanism ideas

[H. Peter Anvin]

Rajeev Bector wrote:
> 
> Thanks for your comment, Peter.
> The problem with using a "driver"
> process is that now you need
> another mechanism to communicate
> with that driver - either
> message queues or shared
> memory or something.
> 

You need that anyway.

	-hpa

Re: new IPC mechanism ideas

[Rajeev Bector]

If your driver is in the kernel,
then you dont need that. All processes
use system-calls (or ioctls) to send
messages and when they do recv(),
they get a pointer to a location
(where they are mapped to via mmap)
and they can read directly. In this
scheme, you dont need any traditional
UNIX IPC mechanism to work.

Thanks,
Rajeev

--- "H. Peter Anvin" <hpa@transmeta.com> wrote:
> Rajeev Bector wrote:
> > 
> > Thanks for your comment, Peter.
> > The problem with using a "driver"
> > process is that now you need
> > another mechanism to communicate
> > with that driver - either
> > message queues or shared
> > memory or something.
> > 
> 
> You need that anyway.
> 
> 	-hpa


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Re: new IPC mechanism ideas

[H. Peter Anvin]

Rajeev Bector wrote:
> 
> If your driver is in the kernel,
> then you dont need that. All processes
> use system-calls (or ioctls) to send
> messages and when they do recv(),
> they get a pointer to a location
> (where they are mapped to via mmap)
> and they can read directly. In this
> scheme, you dont need any traditional
> UNIX IPC mechanism to work.
> 

And the point of this is?

	-hpa

Re: new IPC mechanism ideas

[Alexander Viro]

On Wed, 11 Jul 2001, H. Peter Anvin wrote:

> Rajeev Bector wrote:
[snip]
> > and they can read directly. In this
> > scheme, you dont need any traditional
> > UNIX IPC mechanism to work.
> 
> And the point of this is?

NIH

Re: new IPC mechanism ideas

[Rajeev Bector]

The point is that you can do IPC using
this scheme which is
1) protected (as compared to a shared
   memory (shm) scheme in which any process
   can write anywhere and corrupt
   everything)

2) involves only 1 copy.

Thanks,
Rajeev

--- "H. Peter Anvin" <hpa@transmeta.com> wrote:
> Rajeev Bector wrote:
> > 
> > If your driver is in the kernel,
> > then you dont need that. All processes
> > use system-calls (or ioctls) to send
> > messages and when they do recv(),
> > they get a pointer to a location
> > (where they are mapped to via mmap)
> > and they can read directly. In this
> > scheme, you dont need any traditional
> > UNIX IPC mechanism to work.
> > 
> 
> And the point of this is?
> 
> 	-hpa
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Re: new IPC mechanism ideas

[H. Peter Anvin]

Rajeev Bector wrote:
> 
> The point is that you can do IPC using
> this scheme which is
> 1) protected (as compared to a shared
>    memory (shm) scheme in which any process
>    can write anywhere and corrupt
>    everything)
> 
> 2) involves only 1 copy.
> 

You can still do it in user space, by having individual r/w shm mappings
to the controlling process, and ro mappings to the other processes; it's
still only one copy.

Introducing new forms of IPC adds to the complexity of the programming
model which is already too complex.  It therefore requires substandial
justification (unless you're doing it as a homework project in which case
you shouldn't be posting here), including presenting real-world
applications which cannot be properly served by current forms of IPC.

	-hpa