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