Re: [boost] [future|interprocess] Could futures live in shared memory and synchronize process?

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.

Thanks,
Vicente