Boost logo

Boost :

Subject: Re: [boost] [future|interprocess] Could futures live in shared memory and synchronize process?
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-02-17 12:39:40

----- Original Message -----
From: "Ion Gaztañaga" <igaztanaga_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, February 17, 2009 5:57 PM
Subject: Re: [boost] [future|interprocess] Could futures live in shared memory and synchronize process?

vicente.botet wrote:
> > Hi,
> >
> > As a future is a synchronization mechanism, I was wondering if
> > futures are intrisic of mutil-threaded programs and so they
> > live in the protected process memory or if the concept can be
> > used in a multi-process context and have futures/promises
> > living on shared memory.
> I don't see why do we want to have a future in shared memory. Do you see
> any use case for this?

I was just requesting the same thing. Well, it could be a way to communicate a value between a producer process and a consumer process, so ... the door is open.

> A future is a handle of a concurrency unit that has spawned another
> concurrency unit. A future for processes would be interesting, but
> passing/returning values between processes is not easy and using shared
> memory consumes at least 1 memory page.
> However, I can find useful a future returning "int", just because main
> returns int and a process could spawn other processes and obtain futures
> to them (Boost.Process child is a an example of this approach).

Yes, I see but the future needed in this case will be internal to the spawning process, isnt't it?

> Passing
> objects between processes is not easy, but there are OS mechanisms that
> do similar things like Solaris Doors.

I'll take a look.


Boost list run by bdawes at, gregod at, cpdaniel at, john at