- Boost - lists.boost.org

RE: [boost] Re: Future of threads (III)
by Hurd, Matthew 17 Feb '04

17 Feb '04

> On Behalf Of Matthew Vogt > Allowing the use of asynchronous I/O seems to break the abstraction, which > leaves me wondering why the object should be active? (This is in the > context > of *local* objects, BTW - if the object is remote there is very little > difference between a client/server solution and one using active objects, > is > there?) > > Apologies in advance if I'm not getting something obvious... > > Matt > I think you're confusing the reference to asynch i/o I made, or I'm confused. Recent form would suggest the latter ;-) I was suggesting that a future value is a bit like asynch i/o. I meant that in the sense that with asynch i/o you request something get on with your life and react to it later. A future works like this too, but a little more indirectly, your future is your handler mechanism. You call your function/method which returns a future, say boost::future< double >. When you go to use your future if the value is not yet available then it blocks waiting until it is. If it is available then you use it. This would fit with an active object pattern where the method call returns a result quite nicely, especially if futures where compatible with triggering results on to the queues of other active objects. Though I think the asynch design approach is superior in performance, the semantics of a synchronous approach are often clearer as it looks like a traditional serial program. This would lead to a cute pattern that I haven't seen or thought of before where you get a future value from an active object, but call a method on another active object with that future value ad infinitum and the results just percolate through. :-) Sounds neat but a little impractical I think. The traditional call a method on the Active object and have the results percolate through the pre-allocated workflow of queues and active objects makes a lot more sense. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

RE: [boost] Re: Re: Future of threads (III)
by Hurd, Matthew 17 Feb '04

17 Feb '04

> On Behalf Of scott > Subject: RE: [boost] Re: Re: Future of threads (III) > Do you guys have any thoughts on how to "get work into" the > class (now that it is truly a running thread)? Cos this is > the essence of what an AO is. I think :-) > > Cheers, > Scott > AO's should either have a queue for work or hook into a queue. They are a bit like a worker pool with one worker ;-) Another idiom is a future value, where you ask for a value and don't block until you "read" the value. ACE also has an implementation of this. You can think of it as a bit like overlapped I/O. I also advocate a different architectural neutral style where you can have things at look like function calls that can be: 1. a function call 2. a call to queue work pool or active object 3. an IPC mechanism for same machine transfer, e.g. shared memory 4. a network mechanism, TCP, UDP, TIB or something, for If it can be enabled by a policy driven approach then you can change the architecture of your application by simply changing policies. I think David Abraham's named parameters could help greatly with this approach, along with the serialization lib for marshalling support. This should provide a solid basis for this. I've also thought that perhaps boost::signals might be the correct approach to take for this but I'm unsure. To support this approach you also need mutex aspects that are also policy driven. I am preparing to submit such locking that builds on the existing mutexes and locks. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

4 5

FW: [boost] Re: Re: Future of threads (III)
by scott 17 Feb '04

17 Feb '04

forwarding to boost on the assumption that it was your intention. apologies if i got that wrong. -----Original Message----- From: scott [mailto:scottw@qbik.com] Sent: Tuesday, February 17, 2004 4:42 PM To: 'Jody Hagins' Subject: RE: [boost] Re: Re: Future of threads (III) > -----Original Message----- > From: Jody Hagins [mailto:jody-boost-011304@atdesk.com] > > > The "typical" (i.e., most commonly implemented) method is to use a > thread-safe message queue, coupled with a condition variable. While > there are messages to be processed, the "active object" pulls > them from > the messages queue, and responds appropriately (the AO > specific logic). > When there are no messages available, the AO sits on the condition > variable, awaiting an indication of the arrival of a new > message. I am > sure you understand this, but I could not figure out any other > interpretation of your question... I was responding to your mentioning of the "future" mechanism. Its a perfectly valid mechanism but I was trying to build a case for an implementation of boost::active_object that would never use it. > > I suggest that notions of "function call" should be exorcised from > > discussions that are targeting active objects. That type of thinking > > is perfectly valid in some other thread (oops) but can scuttle work > > targeting active objects; the behaviour (i.e. the code) is > inherently > > in the object. > > > > a client can only submit "worker orders" or "Method Requests" or > > jobs or messages or signals. > > > > I hope there is enough there to make a case :-) > > > I think what you are saying is right in line with traditional methods > for implementing an AO, but I thought we were trying to find alternate > methods, unless I mistakenly misinterpreted the preceeding > communications. > Well, I've learnt to not take anything I send too seriously. These days I am happy if I get the spelling right. I can imagine that there are many approaches to application of the ActiveObject pattern. What I am trying to do so badly is steer discussions away from certain directions. Technically they may be completely justifiable. Strangely I have seen well intentioned implementations of AOs go down some of these paths and the result is not what anyone wants. And nobody really knows where it wandered off target. Personally I believe that what people (developers) _really_ want is the ability to conveniently right a bunch of code fragments that are executed in response to some event (e.g. reception of a message). The collecton of fragments is "the active object". We want the environment to take care of all the nasties such as multi-threading, temporary storage of messages (queueing), routing of message to code fragment and calling of code (passing parameters from message). I think the most insidious error in previous developments has been the assumption of an equivalence between the message sent and a specific function call. Once this assumption is tossed out, implementation becomes more sane and the result is what was targeted. Or closer anyhow :-) The collection of code fragments is the active object. The collection of messages exchanged is a protocol. Until these concepts are to the fore (rather than synchronous, procedural type concepts) then any implementation of boost::active_object will tread the path that others have. actually i have no doubt it would result in something amazing; just not what i was hoping for in an active object :-) > Drinking is not a spectator sport. Cin cin, Scott

2 1

FC++ Lambda
by Darren Cook 17 Feb '04

17 Feb '04

Hi, I've read the lambda sections of the FC++ docs, and the paper on the subject, and am a bit confused how to use it. Could you show the FC++ equivalents of these BLL examples: 1. (from the paper) int a[]={5,3,8,4}; std::for_each(a,a+4,std::cout<<_1<<"\n"); 2. int a[]={5,3,8,4}; std::for_each(a,a+4,std::cout<<constant("v=")<<_1<<"\n"); 3. (a vector of MyClass pointers) std::for_each( tests.begin(), tests.end(), bind(&MyClass::save,_1,f) ); 4. std::for_each( tests.begin(), tests.end(), bind(delete_ptr(), _1) ); 5. (in a spirit parser) Node= +( (+range_p('A','Z'))[bind(&MyClass::on_name, this, _1,_2)] >> +( ch_p('[') >> (*(anychar_p-']'))[bind(&MyClass::on_value, this, _1,_2)] >> ch_p(']') ) ); Darren *: For each I'm doing something like: #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> #include <boost/lambda/construct.hpp> using namespace boost::lambda;

2 3

Boost on tandem
by Hurd, Matthew 17 Feb '04

17 Feb '04

Any experience out there with this? Regards, Matt Hurd IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

[Boost-bugs] [ boost-Bugs-898333 ] Boost.Build fails with Dev-Cpp
by SourceForge.net 16 Feb '04

16 Feb '04

Bugs item #898333, was opened at 2004-02-16 14:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=898333&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Boost.Build fails with Dev-Cpp Initial Comment: Boost.Build fails to build correctly with a bare install of the Dev-Cpp environment (http://www.bloodshed.net/devcpp.html) which is an IDE with a mingw gcc backend. There are two aspects to the problem: 1. Supplying MINGW_INCLUDE_DIRECTORY to bjam does not yield the necessary -isystem directives to the gcc invocations. 2. [More general] The environment-derived path to the archiver executable may contain spaces, but is not escaped when the archiver is invoked. Matt Vogt (mvogt(a)juptech.com) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=898333&group_i… ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: Three questions about the new license
by David Abrahams 16 Feb '04

16 Feb '04

Diane, I want to clarify something you may have missed: the point in question does not concern the Boost license itself, but the way in which our source files declare the license to be applicable to them. They do not contain a copy of the license, but instead make reference to it in a comment, typically: // Copyright David Abrahams 2004. Use, modification and distribution is // subject to the Boost Software License, Version 1.0. (See accompanying // file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) Diane Cabell <dcabell(a)law.harvard.edu> writes: > David Abrahams wrote: > >> Thanks for replying, Diane. >> > (....) >> OK, I think I understand you below, but your wording is a bit >> confusing, so I'll ask for clarification: >> >>>US copyright law only grants the author the right to control public >>> display of the work. >> >> Meaning "the right to control public display of the work is granted >> solely to the author?" > > Meaning, anyone can privately display a work without the author's > permission. There is no copy "right" to control private > displays. [There may be other laws that prevent private display, and > one of them would be the right of the patent owner to prohibit > unauthorized "use" of his invention.] Ugh I don't think we ever considered that "display" would be interpreted other than to mean "display publicly". Does that mean that in the license: Permission is hereby granted, free of charge, to any person or organization obtaining a copy of the software and accompanying documentation covered by this license (the "Software") to use, reproduce, display, distribute, execute, and transmit the Software, and to prepare derivative works of the Software, and to permit third-parties to whom the Software is furnished to do so, all subject to the following: "display" ought to be "display publicly"? >>>See See 17 USC 106 at >>><http://www4.law.cornell.edu/uscode/17/106.html>. Yes, if the right >>>isn't specifically granted, it is not included. >> >> Therefore, the fact that a source file doesn't specifically say that >> "display is subject to the Boost Software License" means that it isn't >> granted at all? The OP was actually concerned that leaving out >> "display" implicitly granted a right to do so. My understanding is >> that it does not. Please confirm/deny. > > Right. Leaving things out does not grant any implied > permission. However (there's always a "however"), it is not necessary > to specifically grant a right to private display [unless there are > patents involved]. I don't think we're concerned about private display. >> This brings up another possible problem, though: if the license >> grants >> certain rights to display, but the source file comment only says that >> "Use, modification, and distribution" are subject to the license, >> perhaps we're failing to grant any display rights. Probably the OP >> was right to suggest that we drop the specific mention of "use, >> modification, and distribution" from source file comments. Even if we >> *are* granting display rights as intended, why risk ambiguity on this >> point? > > It does not grant them, so there is no inconsistency. What is "it"? The license certainly does grant display rights. Are you saying that the part of the license that grants display rights isn't applicable to source files with the comment shown at the top of this message? > If, on the > other hand, you believe that _public_ display should be a right > granted to users We do. > then you should add "public display" everywhere that > you see "use, modification and distribution." This is what makes me think you might have missed the fact that "use, modification and distribution" isn't in the license itself. The suggestion is that "use, modification and distribution" be removed from source files to avoid having to repeat all the rights named in the license. > (....) >>>I'm not sure how you're using the term "file", but you can erase doubt >>>by including it specifically as suggested above. >> >> Sorry, I think I was just bringing up a linguistic technicality. >> These are all copyrightable files. The question is whether a *thing* >> can be subject to a license, or only actions that might be performed >> on that thing. That's why I suggested "licensed under ... " instead >> of "subject to ... ". > > Copyright licenses copying; patents protect operations. Since patent > rights were only recently recognized for pure software, the line is > not really clear in a lot of cases. Interpretation of the licenses > isn't just limited to the linuisitics, however, but looks at the > purpose the agreement is trying to accomplish, what people in the > trade normally intend to happen in such situations, etc. I'm not sure how to apply that information to our situation. My remark about "subject to" was akin to saying "I think you're using a noun as a verb; here's a way to phrase it that avoids grammatical problems." > Diane Cabell > Clinical Program Director > Berkman Center for Internet & Society > Harvard Law School > http://cyber.law.harvard.edu -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: Google links
by Jeff Squyres 16 Feb '04

16 Feb '04

This message was forwarded to the sysadmins of the boost list; Dave asked me to reply here on the list. I am not on the boost list; please CC me on any replies. ---------- Forwarded message ---------- Date: Fri, 13 Feb 2004 16:02:35 -0500 From: David Abrahams <dave(a)boost-consulting.com> Subject: Re: [Osl-sysadmin] Care to respond? On Thu, 12 Feb 2004, David Abrahams wrote: > This showed up on the Boost list... > All the "next in thread" type links I've seen have been internally > consistent. Unfortunately, this renumbering almost certainly means that > external references to the old URL for a given message (e.g. on another > mailing list or newsgroup) will be wrong. From what I've seen of > Google's old links, you usually get a different message, not the one you > expected and not a HTTP 404 for instance. Yup -- definitely an unfortunate side-effect. > It might have been (or still be) a good idea to invalidate completely > the old style URLS to avoid confusion. In consultation with David, we decided not to do this in order to not break all the external (non-search-engine/self-healing) links. > Better still would have been to support both the old and new numberings > in parallel, since you can't know what references exist for the old > URLs. So I thought that we had restored the old numbering, and I thought that Larry (the OSL sysadmin) had checked that. Is there something other than Google (which will eventually fix itself) that is pointing to an incorrect address? -- {+} Jeff Squyres {+} jsquyres(a)osl.iu.edu {+} Research Associate, Open Systems Lab, Indiana University {+} http://www.osl.iu.edu/

3 2

Re: Three questions about the new license
by David Abrahams 16 Feb '04

16 Feb '04

Thanks for replying, Diane. Diane Cabell <dcabell(a)law.harvard.edu> writes: > David Abrahams wrote: > >>>>Do you consider documentation to be software? I don't. >>> >>>No, I don't consider it software either :) I was asking if *in the >>>text of the license* they used the word "Software", with an uppercase >>>'s', as a shortcut for software + docs. That's because it says: >>> >>> Permission is hereby granted, free of charge, to any person or >>> organization obtaining a copy of **the software and accompanying >>> documentation** covered by this license (**the "Software"**) >> >> Now that you remind me, yes, "Software" clearly includes the >> documentation. > > Not always. Often they are treated separately. However, the clause > above ensures that they are both covered. Right. I meant that it clearly includes the documentation **in this case**. >>>>[...] >>>> >>>>>b) IIUC again, the comments we are inserting into source files >>>>> >>>>> >>>>> // Use, modification and distribution are subject to the // >>>>> Boost Software License, Version 1.0. (See accompanying file // >>>>> LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) >>>>> >>>>> >>>>> are unnecessarily verbose (and potentially dangerous). >>>> >>>>Care to elaborate on why you think it's dangerous? >>> >>>Potentially. I was just asking. My question was: the file says use, >>>modification and distribution are subject to the license. Taken >>>strictly I may interpret that only this three things are subject to >>>the license (not display, for instance). If, from a legal point of >>>view, "display" isn't one of these three things then I can display the >>>software without even reading the license. OK, I think I understand you below, but your wording is a bit confusing, so I'll ask for clarification: > US copyright law only grants the author the right to control public > display of the work. Meaning "the right to control public display of the work is granted solely to the author?" > See See 17 USC 106 at > <http://www4.law.cornell.edu/uscode/17/106.html>. Yes, if the right > isn't specifically granted, it is not included. Therefore, the fact that a source file doesn't specifically say that "display is subject to the Boost Software License" means that it isn't granted at all? The OP was actually concerned that leaving out "display" implicitly granted a right to do so. My understanding is that it does not. Please confirm/deny. This brings up another possible problem, though: if the license grants certain rights to display, but the source file comment only says that "Use, modification, and distribution" are subject to the license, perhaps we're failing to grant any display rights. Probably the OP was right to suggest that we drop the specific mention of "use, modification, and distribution" from source file comments. Even if we *are* granting display rights as intended, why risk ambiguity on this point? > >>>>One could simply say >>>>> >>>>>// Subject to the Boost Software License, Version 1.0. (See etc. etc.) >>>> >>>>I don't think a _file_ can be subject to a license, can it? The file >>>>just exists. >>> >>>Hmm... I don't know. It seems to me that the file is the *medium* >>>through which a piece of software is distributed. >> If we were to make a change like that one, I'd say "Licensed under >> the >> Boost...", just to avoid any ambiguity. >> > Whether or not any particular file is capable of copyright protection > would depend on what is contained in the file. US law distinguishes > between facts/data (not protected by copyright) and creative > expression (protectable to the extent that it is severable from the > underlying idea). If a file were just an alphabetical list of names > and addresses, it would not be considered copyrightable in the US > because that's just a bare and unoriginal set of statements of fact. > > I'm not sure how you're using the term "file", but you can erase doubt > by including it specifically as suggested above. Sorry, I think I was just bringing up a linguistic technicality. These are all copyrightable files. The question is whether a *thing* can be subject to a license, or only actions that might be performed on that thing. That's why I suggested "licensed under ... " instead of "subject to ... ". -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

shared_from_this() fails when the object was handled by an auto_ptr<object const>
by Ulrich Eckhardt 16 Feb '04

16 Feb '04

Greetings! Firstly, this is not a regression, the behaviour was present in 1.30, too. I have attached a simple program that should demonstrate the behaviour, but the core is these lines, with foo being derived from enable_shared_from_this: // 1 std::auto_ptr<foo> g(new foo); boost::shared_ptr<foo> f(g); // 2 std::auto_ptr<foo> g(new foo); boost::shared_ptr<foo const> f(g); // 3 std::auto_ptr<foo const> g(new foo); boost::shared_ptr<foo const> f(g); In all three cases, I'd expect to be able to call shared_from_this(). However, only the first two cases really work. I think it boils down to the function detail::sp_enable_shared_from_this() in the ctor of shared_ptr<> that takes an auto_ptr<>. I'm not certain if there is a fix for this and what that fix would be, but I think the problem is that the 'right' function is not taken because at one place we have a 'foo' and at the other we have a 'foo const'. BTW: I believe that a conversion from auto_ptr<T> to shared_ptr<T const> doesn't compile on VC6, but I can't test that ATM(I'm not at work). If any kind soul wants to, they could add such a conversion to the regression-tests. Same goes for volatile probably. greetings and thumbs up Ulrich Eckhardt

4 6