Re: [boost] Multi-processing - Boost future libraries?

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2005-08-18 14:19:56

>>I find Kevlin's "More C++ Threading" paper is really good. Maybe we 
>>should adapt Boost.Thread's implementation to this interface and check
>>if this is better than current one. But it's a quite big task.
>>
>>
> I haven't seen Kevlin's paper.  All I can find is
> http://www.two-sdg.demon.co.uk/curbralan/papers/accu/MoreC++Threading.pdf.
> IIUC, futures are a very useful high-level abstraction but you can't
> solve all the same problems with them as you can with the facilities
> of Boost.Threads.  'Course, I could be wrong, but that paper doesn't
> mention condition variables anywhere so I can't tell.

Sorry, for the word "paper". I was talking about that pdf. Maybe is not 
enough, but we could offer both interfaces, and kevin's approach like a 
wrapper over Boost.Thread. Conditions variables are not mentioned but 
they could be the same as Boost.Thread, I find them very useful.

> Yes.  Especially considering that threads and processes are, um,
> different ;) However, it would be very useful to have some common
> abstractions that allow one to move between the two with little or no
> pain.

That's why I would like to share some utilities like scoped_locks and 
make the interface very similar (mutexes, locks, etc...)

>>Apart from this, I would define more concepts:
>>
>>-> A semaphore: Some say it's dangerous, but sometimes, a semaphore is 
>>tha only way to notify events from drivers and interruptions. 
>>For me, a semaphore is a must.
> 
> 
> Is it possible to abstract away any of the "unsafety" without losing
> applicability to the crucial use cases?

Umm, we have a lot to think here.

>>-> Define a message queue. A message queue should be a must for a 
>>serious C++ standard thread library. Should it use posix-like 
>>priorities? System V approach?
> 
> 
>>-> We can even define a pipe, that can be used in a iostream-like 
>>interface to pass data between threads/processes.
> 
> 
> Nifty.

I will try to define the interface of both classes. I would not reinvent 
the wheel, we have posix message queues and unix pipes, that work great 
and semantics are known. Maybe atomic write issues with pipes could be 
simplified, since we have a message queue, for the messages, and use the 
pipe like a stream oriented, unstructured flow.

> What we really need is someone/people to step up to the plate and take
> responsibility for development, maintenance, and documentation of
> relevant libraries.  We need more than ideas; we need leadership.
> That isn't to say it has to be done by one person alone, but at least
> someone needs to rally the energy of Boosters with the interest and
> expertise to tackle the problems.  Maybe you and Paul can do something
> together?

I'm ready to make a new Shmem snapshot, stop the development of Shmem 
(well trivial bug-fixes only) and work on Boost Thread's interface. Not 
that I am an expert in threads, I'm talking just about the interface, 
but at least I will start making noise about this. If we have a 
definitive boost thread interface, I would then adapt Shmem to this 
interface. Last time I looked, Michael Glassford was mantaining 
Boost.Thread, and he had good ideas, so he could help a lot here.

Regards,

Ion