Re: [Boost-users] [Asio]Question about error_code when socket::close

Subject: Re: [Boost-users] [Asio]Question about error_code when socket::close
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-05-16 21:47:54

On Sun, May 16, 2010 at 4:00 AM, 鑫炜廖 <cometliao_at_[hidden]> wrote:
> Igor R <boost.lists <at> gmail.com> writes:
>>
>> > I want to distinguish the error_code set by calling socket::close from
>> > any other ways (like system error, network
>> > error, etc), otherwise, I can't determine whether I should delete the
>> > object in async handlers, because
>> some have already been deleted after I call socket::close. If
>> boost::asio::error::operation_aborted
>> definitely means "socket::close is called", I can distinguish this
>> situation.
>>
>> It seems to be rather error-prone approach. One day, when your
>> application will have grown a bit, you'll find yourself hunting weird
>> segfaults / access-violations.
>>
> But when should I delete the object after I call socket::close? May be
> there's no async handler, so just deleting object in handlers leads to
> memory leak.
>> > I've tried using boost::weak_ptr with boost::bind,but the performance
>> > decrease dramatically.
>>
>> Did you run a performance profiler with fully-optimized application
>> and really discovered that the bottle-neck is in shared_ptr's?! This
>> would be really surprising...
>>
> I've tested it separately, when binding a weak_ptr/shared_ptr with a member
> function, it will cause extra new/delete operations, but raw pointer will
> not(gcc 4.4.1, boost 1.4.3).The former way is about 20 times slower,as a
> frequently operation, it seems not acceptable.

That is because you are most likely using the inefficient creation
style, probably like this:
  shared_ptr<myClass> myPtr(new myClass(arg1,arg2));
Which will also new a struct inside the shared_ptr that holds that
pointer and bookkeeping information.  If you have read the shared_ptr
documentation, the efficient creation style is this:
  shared_ptr<myClass> myPtr = make_shared<myClass>(arg1,arg2);
Which will new both your class and the bookkeeping information in the
same place in memory, increasing both the speed of creation (only one
new), and speed of accessing (better cache coherency).

When creating your objects at the same time (literally) as the
shared_ptr, that should fix most of those speed issues.