Hi to those folks that contributed to some recent messages related to threads, active objects and reactive objects. Mostly this was Matthew Vogt. So this is mostly for Matthew but anyone else can certainly respond. I have been interested in proposing an alternative threading model to that provided by boost.threads. Quite sensibly somone suggested that any alternative should leverage the existing facillity. J. Garland also provided the reference to the work of Schmidt; the ActiveObject pattern. I have been trying to slice off a piece of a larger library that I have been working on. Defining something that would be appropriate as a proposal to boost is very difficult. I started a requirements document to that end which become more of a research paper. Its convinced me that it is probably a no-go. The fundamental reason would be the scope of anything with pretentions to calling itself "active objects". It requires not only a significant body of supporting code but requires quite a cultural change by users (i.e. developers). I would have posted the document but it is quite long. If anyone is interested in it then just ask for it. Its a rambling piece but it has been reviewed :-) Cheers, Scott
scott <scottw <at> qbik.com> writes:
I would have posted the document but it is quite long. If anyone is interested in it then just ask for it. Its a rambling piece but it has been reviewed
Hi Scott As the upcoming boost::fsm submission contains something that could be considered a subset of what an ActiveObjects library could do I'm certainly interested in your findings. Please mail me the document. Thanks & Regards, Andreas
At 23:08 11/03/2004, you wrote:
Hi to those folks that contributed to some recent messages related to threads, active objects and reactive objects. Mostly this was Matthew Vogt.
So this is mostly for Matthew but anyone else can certainly respond.
<snip> I would have posted the document but it is quite long. If anyone is interested in it then just ask for it. Its a rambling piece but it has been reviewed :-)
Cheers, Scott
Hi Scott, sorry for being quiet... too much other (paid) work to do :o( I'm interested in your spec.. if you can email me direct (boost@blewett.nildram.co.uk) I'll have a look, but at this time I have minimal time spare until May'ish :o( Going back "to basics".... I think you said (in one of the messages I saw) that there was a lot of associated code needed to support (In)active objects.. thats the conclusion that I came to, along with how protective it should be (how thread aware the user needs to be), how it imposes on the developers thought process (normal functional coding v state machines).. and intern wether it was in the scope of boost, or a framework in it's own right. In retrospect, I wonder if some building blocks are needed first? Personally it would be nice if boost helps with the development of multi-thread applications. In some form it does already with threads, mutexs etc, but for me it's not quite enough.. to me multi-thread starts to imply being scaleable. IMHO (apart from inter-thread comms) that means support for asynchronous i/o. For example if boost.sockets only supported blocking calls, I would be disappointed, at a minimum i'd expect to be able to write a "commercial" webserver. This is where I run into problems... how far should boost abstract the underlying system? Yes it would be nice to have a well defined, standard, tested common asynchronous i/o library... but is it an abstraction too far? Regards Mark --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.614 / Virus Database: 393 - Release Date: 05/03/2004
Mark Blewett <boost@blewett.nildram.co.uk> writes:
[snip: supporting multi-threading implies supporting scalability]
IMHO (apart from inter-thread comms) that means support for asynchronous i/o. For example if boost.sockets only supported blocking calls, I would be disappointed, at a minimum i'd expect to be able to write a "commercial" webserver.
I agree, supporting asynchronous I/O is, IMO, an absolute requirement for a boost socket library.
This is where I run into problems... how far should boost abstract the underlying system? Yes it would be nice to have a well defined, standard, tested common asynchronous i/o library... but is it an abstraction too far?
No, I don't think so. Writing an efficient portable asynchronous (socket/pipe) I/O library which also easily supports user-defined protocol layers, and which ideally also elegantly supports blocking and non-blocking I/O within the framework as well is not an easy task, but it can be done. -- Jeremy Maitin-Shepard
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]On Behalf Of Jeremy
[snip: supporting multi-threading implies supporting scalability]
IMHO (apart from inter-thread comms) that means support for asynchronous i/o. For example if boost.sockets only supported blocking calls, I would be disappointed, at a minimum i'd expect to be able to write a "commercial" webserver.
I agree, supporting asynchronous I/O is, IMO, an absolute requirement for a boost socket library.
Hmmmm. Not sure if this interesting to you guys or not. Finished the "inter-thread comms" and then implemented async I/O on top of the first. I now have; template <typename protocol> struct TCP_connect template <typename protocol> struct TCP_listen which might be instantiated thus; machine_address smtp = create< TCP_listen<SMTP> >(); Expressing the whole establishment of endpoints using the state machine asyn messaging worked out well. A real nasty with tackling it from the I/O point of view is that everything can become "I/O event"-centric. And at application level (where we would like to live) that is a skewed perspective, e.g. arrival of a TCP block does not equal an application level message. Coping with that one nasty seems to consume big chunks of everything :-)
This is where I run into problems... how far should boost abstract the underlying system? Yes it would be nice to have a well defined, standard, tested common asynchronous i/o library... but is it an abstraction too far?
Yes. Quite difficult to split. As an indication the cleanest piece I can split off seems to be my message type, i.e. another variant. And who wants another one of those?! The rest is intrinsically bound :-( Cheers, Scott
participants (4)
-
Andreas Huber -
Jeremy Maitin-Shepard -
Mark Blewett -
scott