Re: [boost] [Review] Shmem

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-02-12 04:29:44

Hi David,

> I find that a rather self-fulfilling statement.  It's insulting to
> characterize my expression of concern for this design principle as
> flame.

I've not tried to insult you. So if it was the case, please forgive me.

>> that does not benefit Boost or Shmem itself.
> 
> I think if you tried to learn something from my comments, Shmem's
> design would in fact benefit.

>> What I want to know is if you consider a library rejection reason if 
>> Shmem provides *both* RAII *and* open/close functions.
> 
> I consider a design that specifically accomodates a version of C++
> with some of its features turned off at the expense of guarantees that
> one can otherwise achieve -- especially if that expense is completely
> avoidable -- cause for concern.  And based on your response to my
> concerns so far I would be inclined to worry about the future of the
> library and your responsiveness to other legitimate concerns.  All
> that would tend to bias me towards voting against this library.  It's
> not a reason for a "no" vote in and of itself, but if I had any energy
> left to do an actual review, I would certainly be motivated to find
> other areas where the design looked problematic to me.

I see. Obviously, since I've been defending the other alternative, I 
don't see the double-alternative so dangerous. But I see that current 
open/close *only* view is dangerous. After thinking it a bit, if 
boosters think that double way is too dangerous (well, some other has 
expressed the opposite view and wants alternatives) I'm ready to remove 
open/close expressions and implement a RAII only final version. But 
surely someone won't agree with it and it might have good reasons. But I 
repeat: I propose a RAII only version. I don't think this aspect is the 
most important aspect of Shmem.

>> The optional may be or not constructed, and you have to check that
>> before using optional. I'm trying to avoid dynamic allocation so
>> scoped_ptr is not a good enough solution in my opinion.
> 
> The scoped pointer or optional would be employed by the *user* of
> shmem who wants to achieve that difference in lifetime.

Yes. But I wanted to avoid Shmem users to be forced to use dynamic 
allocation or optional if the want two-phase initialization. Re-reading 
the proposed C++ N1883 paper Kevlin Henney wrote about threader-joiner 
architecture similar to smart pointer/new combination:

class threader
{
    public:
    template<typename nullary_function>
    joiner operator()(nullary_function threadable);
...
};

template<typename threadable>
joiner<return_type<threadable>::type> thread(threadable function)
{
    return threader()(function);
}

int main ()
{
    //Class approach
    threader run;
    joiner wait = run(first_task);
    //or function approach
    jointer wait2 = thread(second_task);
}

Couldn't be an alternative something similar with Shmem primitives:

shared_memory_handle shm = shared_memory(/*open, open/create overloads*/);

shm would be like the proposed joiner (CopyConstructible, Assignable, 
and DefaultConstructible and Shareable (via an internal shared_ptr, for 
example) so that I could have a shared_memory_handle member in a class 
that can be initialized when I want. Much like a shared_ptr member that 
can be default constructed but only initialized though an external "new 
T" operation.

I see that since shared_memory_handle has default constructor it can be 
also a two-phase initialization class (much like shared_ptr) but do you 
think this architecture is acceptable or you think it has the same 
problems as the previous one? I'm trying to offer some alternatives I've 
seen in proposed WG21 papers (but I'm ready to offer a RAII only 
interface, as I've said).

>> And for example, to open raii I need 3 arguments, and to create raii
>> resource I need 4.
>>
>> class Holder
>> {
>>     RAII  raii;
>>     public:
>>     Holder(/*some conditions*/)
>>        : raii(/*Create or open depending arguments,
>>                 and other temporary results*/)
>>     {}
>> };
> 
> So make your constructors more flexible.
> 
>   class Holder
>   {
>       RAII  raii;
>       public:
>       Holder(/*some conditions*/)
>        : raii( 
>              generate_initializer( 
>                  arguments and other temporary results 
>              ) )
>       {}
>   };
> 
> 
> If you use the parameter library it's especially easy to accomodate
> this sort of interface.

I see. I can wrap all parameters in a single object to avoid this problem.

> Then you clearly don't understand me at all.  I'm arguing that
> interfaces that easily lead to zombie states make components harder to
> use and code harder to think about.  Just providing a *way* to avoid
> the zombie state does not help me know that I can operate on such an
> object that I'm passed by reference without first making sure it's not
> a zombie.

Well, someone can pass you shared_ptr that is empty and we don't forbid 
an empty shared_ptr. I think that functions can establish preconditions 
to say what kind of parameters they expect.

>> I think that apart from this C++ aspect of your knowledge, there is
>> plenty of your C++ knowledge that you can use in other aspects of
>> the library. And I'm really interested in them. Specially, if they
>> are related to correct uses or better idioms like the previous
>> one. And I want to support those idioms. I just want to provide some
>> alternatives apart from your advices.
> 
> I think I've used up most of my available energy on this one.  :(

Ok. But don't say you were not invited to the party ;-) Now, seriously, 
I'm ready to offer a RAII only approach if the above described 
alternative is considered also a bad design. I would only need a 
class/library that you think it implements well this RAII approach (what 
kind of exceptions it throws, and so on) to have some good model. I do 
understand your concerns and I think that Shmem has much more to offer 
than this initialization problem.

Regards,

Ion