------- Start of text attachment ------- Content-Type: text/plain ; charset="iso-8859-1" Content-Transfer-Encoding: UUE Content-Disposition=inline

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Thursday 06 November 2008 03:11 am, Franz Alt wrote:

...

have you got some examples with the usage of the extended_slot_type / connect_extended? In your documentation there is no example.

Attached is an example program. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJEwuq5vihyNWuA4URAkBpAKCoJo5GTm6MPc27FjsBBvx5OqjORgCfXx9i oL5Hbtr/v4NMjinkLWlosUk= =fETt -----END PGP SIGNATURE----- ------- End of text attachment -------

------- Start of text attachment ------- Content-Type: text/plain ; charset="us-ascii" Content-Transfer-Encoding: UUE MIME-Version=1.0 Content-Disposition=inline

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------- End of text attachment -------

Hi, what advantages has an extended slot contrary to a normal slot? I've look at the libraries source code and at your example but I don't have the feeling that the extended slots are much "better" than the normal ones. Is there a special case for the extended slot? Franz

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Friday 07 November 2008 08:39 am, Franz Alt wrote:

...

Hi,

what advantages has an extended slot contrary to a normal slot? I've look at the libraries source code and at your example but I don't have the feeling that the extended slots are much "better" than the normal ones. Is there a special case for the extended slot?

It is there to make the slot's connection available to it in a convenient and thread-safe way. Otherwise, the connection object is not available until after the slot has already been connected (and might get invoked by another thread). See this post for a more verbose rationale:

http://lists.boost.org/Archives/boost/2008/10/142995.php -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJFFBD5vihyNWuA4URAvz7AJwOWLCzi2iC7IiEwVDnq6MZmdRjVgCg19Y+ yGgbiDExE63G3kLEFx5wppM= =f4zj -----END PGP SIGNATURE----- _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

In the documentation there is only one sentence about the extended slot. From a pure user point of view it's very confusing what is the advantage of the extended slots contrary to the normal ones. I think the documentation makes it not clear when to use what type of slot. Do you plan to update the documentation at this point? I've looked at the documentation for the word 'thread' and I've found it only three times. I think the normal user wants to know more detailed informations about the thread safe signals library at a thread context. Do you also plan to enrich the documentation here?

----- Original Message ----- From: "Frank Mori Hess" <frank.hess@nist.gov> To: <boost@lists.boost.org> Sent: Friday, November 07, 2008 5:45 PM Subject: Re: [boost] [signals2] extended_slot_type bug with preferred syntax

...

I've looked at the documentation for the word 'thread' and I've found it only three times. I think the normal user wants to know more detailed informations about the thread safe signals library at a thread context. Do you also plan to enrich the documentation here?

Hmm, yes I think adding a section on thread-safety to the design overview would help a lot.

Could you scketch how do you plan to do this section if the libarry is accepted before the review manager gives the result of the review? Thanks, Vicente

----- Original Message ----- From: "Frank Mori Hess" <frank.hess@nist.gov> To: <boost@lists.boost.org> Sent: Thursday, November 13, 2008 11:30 PM Subject: Re: [boost] [signals2] extended_slot_type bug with preferred syntax

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Wednesday 12 November 2008 05:32 am, vicente.botet wrote:

...

----- Original Message ----- From: "Frank Mori Hess" <frank.hess@nist.gov>

...

...

Hmm, yes I think adding a section on thread-safety to the design overview would help a lot.

Could you scketch how do you plan to do this section if the libarry is accepted before the review manager gives the result of the review?

The design overview would:

specify which classes/methods are protected by internal mutexes

explain why the shared_ptr/weak_ptr connection management is relevant to thread-safety, and similarly for signal::connect_extended()

explain why the postconstructor stuff exists (no shared_from_this() for tracking in constructors).

go over some possible choices for the Mutex template type parameter of a signal

step through signal invocation, describing when it locks/unlocks internal mutexes, what connection list it uses, and when it sees concurrent disconnections/connections.

The rationale section would get:

some notes on changes like last_value/optional_last_value and boost::trackable.

Independently of if the library is accepted or accepted conditionally, I would like to participate in a mini-review with all the material you plan to add and improbe. Good Luck, Vicente