On Apr 12, 6:51 am, n...@animats.com (John Nagle) wrote:
> Mathias Gaunard wrote:
> > On Apr 10, 8:56 pm, John Nagle <n...@animats.com> wrote:

> >>     Once you start using a callback-based framework, you have to do
> >>everything that can delay via that framework.  Otherwise you stall the
> >>callback engine.  So the introduction of a callback-based framework
> >>determines the overall design of the program.

> > An obvious solution is to run the whole engine in its own thread.
> > However, doing so automatically would reduce the user's control, who
> > couldn't choose on which thread (or pool of threads) he wants to run
> > it on.

>      Then you have to address thread-safety issues.  If you want
> to change "asio" list of work to do, and it has its own thread, how and
> what do you lock?  "asio" would need a lock that's locked when
> "asio" isn't in its waiting state.  That doesn't seem to have been
> addressed.

Part of that should be asio's problem, not the users.  But you
do have to face the fact that you force threads down the user's
throat, whether he wants them or not, and that the user must
take into account that he doesn't know in what thread the
callback may be executed, which seriously limits his options,
and means that he suddenly has to worry about synchronizing
things.  (Note that it can be very tricky, since the callback
may also be called in the same thread.  At a moment when the
thread holds the locks needed.  And that those locks are not
necessarily recursive.)

Personally, I'd rather expose the threading: make the io
blocking, and leave it up to the user to split it off into a
second thread if he needs non-blocking.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 12, 6:51 am, n...@animats.com (John Nagle) wrote:

>      Then you have to address thread-safety issues.

As far as I can see, those are perfectly addressed in the current
proposal.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2175.pdf

See chapter 4.6, threads.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Thu, 12 Apr 2007, James Kanze wrote:

> If the callbacks are based on a threading model; i.e. the event
> control runs in its own thread, then you have to take into
> account the fact that the user's callback may be (and probably
> will be) called from a thread the user doesn't even know about,

Not in asio. It guarantees that callbacks will only be called on threads
explicitly given to the event manager (the io_service in asio terms) via
its run() method.

> and you have to provide a mechanism for the user to stop the
> thread (which he doesn't know about) in order to ensure clean
> shutdown.

Not really. You only need to provide a way to signal the event manager to
stop.
Asio does that automatically when no work is left (which should be the
normal way of shutting down for such systems) or by calling the
interrupt() method.

So the remaining complaint is that you need to give the event manager a
thread in the first place, one that can't do other things (like go into a
native Win32 event loop). This is, admittedly, a shortcoming. There are
two obvious solutions, both of which ought to be possible.

In asio terms, the first solution would be to add a try_run() method that
returns once there is no immediate work to do, instead of blocking until
all work is complete. This would be a polling approach.
The second would work through futures and promises, and since those are
under review anyway, a solution might be developed.

Simple blocking I/O is not sufficient, anyway. It simply doesn't scale to
a situation where there may be many simultaneous network connections open,
but work comes in only sporadically through them - a typical web server
with keepalive connections. With simple blocking I/O, at the very least
you need one thread for every network connection, with an additional
thread for listening for incoming new connections. A select()-like system
is needed at the very least, so that one thread can simultaneously block
on everything and wake up whenever anything becomes active.

And in fact, asio can be used in this scenario, too. Just have your main
thread call run(). You have the guarantee that no other thread will
execute the callbacks, so no synchronization is necessary. (As opposed to
simple blocking I/O, where many threads are necessary and thus they
probably need synchronization.)

Bottom line: if asio had a non-blocking run() that just executes
immediately available work and returns, I think everyone ought to be
happy.
Even though personally I don't think a polling approach would be terribly
useful.

Sebastian Redl

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Gianni Mariani wrote:
> James Kanze wrote:
>
>> On Apr 12, 6:50 am, gi3nos...@mariani.ws (Gianni Mariani) wrote:
>>
>>> John Nagle wrote:
>>>
>>>>    Yes, that's right.
>>
>>
>>
>>>>    The basic concept of Boost's "asio" is that
>>>> "boost::asio::demuxer::run()"
>>>> owns the main event loop and calls everything else. That's a
>>>> framework, not a library.
.
>>
>>
>>
>> He just did.  He objects to having a library component take over
>> the basic loop.

    Yes.
>>
>> If the callbacks are based on a threading model; i.e. the event
>> control runs in its own thread, then you have to take into
>> account the fact that the user's callback may be (and probably
>> will be) called from a thread the user doesn't even know about,
>
>
> and this is a problem because ?

     Then you have to deal with locking, of course.

     It's quite possible to have an event-driven model and a threading model
play well together.  It's not entirely clear how well that works for "asio".
"asio" does support threads, but (as far as I can tell, given that the
documentation is tutorial) assumes that "asio" is in charge of all the threads.

     "An boost::asio::strand guarantees that, for those handlers that are
dispatched through it, an executing handler will be allowed to complete before
the next one is started. This is guaranteed irrespective of the number of
threads that are calling boost::asio::io_service::run(). Of course, the handlers
may still execute concurrently with other handlers that were not dispatched
through an boost::asio::strand, or were dispatched through a different
boost::asio::strand object."

     So there's a concurrency model in "asio", but it assumes that "asio" is
in charge of concurrency.  That's rather framework-like.

     Also, one of the primary motivations for a single-thread event driven
model is that programmers can avoid dealing with real locking and concurrency,
which many programmers find difficult.

     C++ needs a good concurrency model.  Especially since the number
of CPUs per computer is increasing rapildy.   But this may not be it.
What's going on in that area?

     This is tough.  The Python community has "Twisted", which is an event
driven I/O framework roughly comparable to "asio".  The problem with "Twisted"
is that every library now has to be converted to a "Twisted version", using
Twisted's event model.  Twisted ends up being used for web services, but not
much else.

     John Nagle

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hi John,

John Nagle wrote:
 >     Then you have to address thread-safety issues.  If you want
 > to change "asio" list of work to do, and it has its own thread, how
 > and what do you lock?

Nothing.

 > "asio" would need a lock that's locked when "asio" isn't in its
 > waiting state.  That doesn't seem to have been addressed.

It is covered in sections 4.6.1 and 5.3.2.5 of N2175. In practical
terms: it is safe to make concurrent calls to an io_service object; it
is safe to make concurrent calls to different socket objects (or other
I/O objects) whether or not they share an io_service object; it is safe
to concurrently call a socket object and the associated io_service
object.

Cheers,
Chris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hi James,

James Kanze wrote:
 > If the callbacks are based on a threading model; i.e. the event
 > control runs in its own thread, then you have to take into
 > account the fact that the user's callback may be (and probably
 > will be) called from a thread the user doesn't even know about,
 > and you have to provide a mechanism for the user to stop the
 > thread (which he doesn't know about) in order to ensure clean
 > shutdown.

Callbacks to user code in the proposal may only occur under certain
well-defined conditions, and never from a thread that the user doesn't
know about. See sections 4.6.2 and 5.3.2.7 in N2175 for more
information.

Cheers,
Chris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hi Sebastian,

Sebastian Redl wrote:
> In asio terms, the first solution would be to add a try_run() method that
> returns once there is no immediate work to do, instead of blocking until
> all work is complete. This would be a polling approach.

The proposal (as well as Boost.Asio 0.3.8rc2 and the version in Boost
CVS) already provides io_service::poll() and io_service::poll_one() for
this.

Cheers,
Chris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hi John,

John Nagle wrote:
 >     The basic concept of Boost's "asio" is that
 > "boost::asio::demuxer::run()" owns the main event loop and calls
 > everything else. That's a framework, not a library.

You are looking at an ancient version of Boost.Asio, and certainly one
that was before the Boost review process. The submitted proposal is
closest to 0.3.8rc2.

 >     Frameworks tend to take over the program design.  Try using
 > "asio". and some GUI framework which also wants to own the event
 > loop, in the same program.  Sometimes multiple frameworks can be made
 > to play together using multiple threads, but it's usually not easy.

People do successfully use Boost.Asio in GUI applications. The most
common designs are to either:

- call io_service::run() in a background thread; or

- periodically call one of io_service::poll(), io_service::poll_one() or
   io_service::run_one() from a GUI-driven event (such as a timer).

In the case of using a background thread, you can customise the
invocation of the application's completion handlers so that they are
executed from the GUI's event loop.

Yes, it is possible to write programs where you turn over control to
Boost.Asio by calling io_service::run(). For certain problems this is
the right design choice, but I strongly disagree with the assertion that
it is imposed. In particular, the use of generic function objects as
callbacks (as opposed to deriving from an abstract base class as in a
traditional framework) is intended to give a lot of flexibility in the
use of the library.

For example, Boost.Asio is designed to play nicely with forthcoming
standard support for threads and futures:

    future<size_t> bytes_read;
    async_read(sock, buffer, set_this_future(bytes_read));
    ... do other stuff ...
    size_t b = bytes_read();

Alternatively, you might prefer a predominantly synchronous design and
only switch to asynchronous operations when you need to do multiple
operations at once:

    read(sock, request);
    ...
    write(sock, reply);
    ...
    error_code read_result = not_done_yet;
    async_read(sock, request, var(read_result) = _1); // Boost.Lambda
    error_code write_result = not_done_yet;
    async_write(sock, request, var(write_result) = _1);
    while (io_service.run_one())
    {
      if (read_result != not_done_yet) ...
      if (write_result != not_done_yet) ...
    }
    ...

Anyway, there are more design options than I can do justice to in one
posting. I hope the different ways in which Boost.Asio can be used
demonstrate that I have designed it to be as un-framework-like as
possible.

Cheers,
Chris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 12, 4:41 pm, gi3nos...@mariani.ws (Gianni Mariani) wrote:
> James Kanze wrote:
> > On Apr 12, 6:50 am, gi3nos...@mariani.ws (Gianni Mariani) wrote:

    [...]
> > If the callbacks are based on a threading model; i.e. the event
> > control runs in its own thread, then you have to take into
> > account the fact that the user's callback may be (and probably
> > will be) called from a thread the user doesn't even know about,

> and this is a problem because ?

Are you serious.  My code is called, asynchronously, in a
different thread, and I don't even know that the application is
multithreaded?  That can't work.

> > and you have to provide a mechanism for the user to stop the
> > thread (which he doesn't know about) in order to ensure clean
> > shutdown.

> Ah, that's called a destructor.

I'm not sure I like that, at all.  What happens if the other
thread doesn't collaborate?

> Some programmers object to that and
> want a special call, however I find that whenever I want to shut down I
> also want to destuct and so the destructor is an excellent was to signal
> a "thread" object to get out quick.

Yes, but I don't want to destruct until the other thread is good
and ready.  In fact, normally, it is the other thread that does
any destructing which concerns his objects.

> The destructor will wait for the
> thread to exit before the object is truly destroyed.

In other words, the program may hang, and never terminate.

> Maybe I see this as a solved problem and I don't get it.

Maybe you've just not pushed it to the limit, to see what
happens.  Using destructors to terminate threads is a definite
loser.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 4/12/07 11:53 AM, in article
1176384727.631617.130380@n59g2000hsh.googlegroups.com, "James Kanze"
<james.kanze@gmail.com> wrote:

> On Apr 12, 6:51 am, n...@animats.com (John Nagle) wrote:
>> Mathias Gaunard wrote:
>>> On Apr 10, 8:56 pm, John Nagle <n...@animats.com> wrote:
>
>>>>     Once you start using a callback-based framework, you have to do
>>>> everything that can delay via that framework.  Otherwise you stall the
>>>> callback engine.  So the introduction of a callback-based framework
>>>> determines the overall design of the program.

A call to an asynchronous I/O routine returns immediately, so even if delays
exist in the communications channel - the program itself is not delayed.
Moreover, it is not possible to "stall" an asynchronous I/O operation
because - being "asynchronous" - the amount of time needed for the I/O
operation to complete is independent of - and unaffected by - the program'
activities during the same span of time.

Even a program that processes callbacks at a leisurely rate, does not hold
up the I/O operation's completion. After all, the callback executes only
after the request has finished. So although a program may delay its
recognition of the completed I/O operation - it was not able to delay the
start of the the request itself.

>>> An obvious solution is to run the whole engine in its own thread.
>>> However, doing so automatically would reduce the user's control, who
>>> couldn't choose on which thread (or pool of threads) he wants to run
>>> it on.

Since the support for threaded execution is not a prerequisite of the asio
library: the only thing "obvious" about this proposed solution (for a
non-existent problem) is the impossibility of implementing it.

>>      Then you have to address thread-safety issues.  If you want
>> to change "asio" list of work to do, and it has its own thread, how and
>> what do you lock?  "asio" would need a lock that's locked when
>> "asio" isn't in its waiting state.  That doesn't seem to have been
>> addressed.

So the only effect of implementing this "solution" is to create all sorts of
potential problems and needless complications - none of which existed in the
original implementation.

> Part of that should be asio's problem, not the users.  But you
> do have to face the fact that you force threads down the user's
> throat, whether he wants them or not, and that the user must
> take into account that he doesn't know in what thread the
> callback may be executed, which seriously limits his options,
> and means that he suddenly has to worry about synchronizing
> things.  (Note that it can be very tricky, since the callback
> may also be called in the same thread.  At a moment when the
> thread holds the locks needed.  And that those locks are not
> necessarily recursive.)

The callback is always executed on the same thread that made the I/O request
(and likely the only thread in the entire program). So what would these
locks be doing, exactly?

> Personally, I'd rather expose the threading: make the io
> blocking, and leave it up to the user to split it off into a
> second thread if he needs non-blocking.

What threading?

Greg

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 13, 12:46 am, Sebastian Redl <e0226...@stud3.tuwien.ac.at>
wrote:
> On Thu, 12 Apr 2007, James Kanze wrote:
> > If the callbacks are based on a threading model; i.e. the event
> > control runs in its own thread, then you have to take into
> > account the fact that the user's callback may be (and probably
> > will be) called from a thread the user doesn't even know about,

> Not in asio. It guarantees that callbacks will only be called on threads
> explicitly given to the event manager (the io_service in asio terms) via
> its run() method.

In other words, the problem has been recognized and addressed.
That's very good.

> > and you have to provide a mechanism for the user to stop the
> > thread (which he doesn't know about) in order to ensure clean
> > shutdown.

> Not really. You only need to provide a way to signal the event
> manager to stop.

And it takes care of the threads, transparently?

> Asio does that automatically when no work is left (which should be the
> normal way of shutting down for such systems) or by calling the
> interrupt() method.

Just curious, but "no work left" means what?  My vision of this
(perhaps mistaken) is that of a server, which is up 100% of the
time, waiting for connections.

> So the remaining complaint is that you need to give the event manager a
> thread in the first place, one that can't do other things (like go into a
> native Win32 event loop).

This means, for example, that I can't use asio in a single
threaded application?  (Unless an application needs to be
multithreaded, I prefer to keep it single threaded.)

    [...]
> Bottom line: if asio had a non-blocking run() that just executes
> immediately available work and returns, I think everyone ought to be
> happy.
> Even though personally I don't think a polling approach would be terribly
> useful.

It depends.  It would work if you had some way of waking up the
main loop when there was an incoming event to be treated.

The problem with standardizing sockets, as I see it, is that
there are two incompatible approaches, and both have their
advantages.  From what you've just said, I think that asio
adopts one approach, which is fine, as long as the other
approach (single thread, with main process loop) is available as
well.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hi John,

John Nagle wrote:
 >     Then you have to deal with locking, of course.

Actually Boost.Asio can be used to develop single threaded or
multithreaded servers without recourse to explicit locking.

 >     It's quite possible to have an event-driven model and a threading
 > model play well together.  It's not entirely clear how well that works
 > for "asio".

 From what I've heard, it seems to work pretty well :)

 > "asio" does support threads, but (as far as I can tell, given that the
 > documentation is tutorial) assumes that "asio" is in charge of all the
 > threads.

I'm sorry, perhaps I don't understand what you mean by "in charge of all
the threads". If you mean that Boost.Asio must be in control of all
threads in the process, then that is certainly not the case.

 >     "An boost::asio::strand guarantees that, for those handlers that
 > are dispatched through it, an executing handler will be allowed to
 > complete before the next one is started. This is guaranteed
 > irrespective of the number of threads that are calling
 > boost::asio::io_service::run(). Of course, the handlers may still
 > execute concurrently with other handlers that were not dispatched
 > through an boost::asio::strand, or were dispatched through a different
 > boost::asio::strand object."
 >
 >     So there's a concurrency model in "asio", but it assumes that
 > "asio" is in charge of concurrency.  That's rather framework-like.

Boost.Asio isn't in charge of concurrency, but you may use Boost.Asio to
manage the concurrency of some or all of your completion handlers. The
io_service::strand class is simply a tool to prevent concurrent
invocation of completion handlers.

Of course, you may choose to use explicit locking to achieve this.
However, if there is contention on a lock, one of the threads may be
stalled until the lock is acquired. This can hold up the invocation of
any other completion handlers that are ready to run.

Strands, on the other hand, do not have this problem. The io_service
won't invoke a completion handler if there's another handler already
executing within the same strand. A completion handler from another
strand (or with no strand) can be executed instead.

 >     Also, one of the primary motivations for a single-thread event
 > driven model is that programmers can avoid dealing with real locking
 > and concurrency, which many programmers find difficult.

Yes, I agree completely! This is why I personally recommend
single-threaded designs as the default choice when using Boost.Asio
(kind of like the recommendation to prefer std::vector by default).

 >     C++ needs a good concurrency model.  Especially since the number
 > of CPUs per computer is increasing rapildy.

Boost.Asio also supports a range of other design options that may be
used to better utilise multiple processors or cores. Examples include an
io_service combined with a thread pool, one io_service per CPU, and even
pipelined architectures where different tasks are assigned separate
threads and/or CPUs.

Cheers,
Chris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 14 avr, 03:21, "James Kanze" <james.ka...@gmail.com> wrote:

> I think that asio
> adopts one approach, which is fine, as long as the other
> approach (single thread, with main process loop) is available as
> well.

asio *is* single thread with one main process loop.
I don't understand your point.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Mathias Gaunard wrote:
> On 14 avr, 03:21, "James Kanze" <james.ka...@gmail.com> wrote:
>
>
>>I think that asio
>>adopts one approach, which is fine, as long as the other
>>approach (single thread, with main process loop) is available as
>>well.
>
>
> asio *is* single thread with one main process loop.
> I don't understand your point.

     That's the problem.

     Consider that "Tk" is also single thread with one main
process loop.  As are most GUI libraries.  Now try to make
both play together.  It's not fun.

     This is called the "duelling event loop scenario".  There's
a user discussion of this at

     http://osdir.com/ml/lib.boost.asio.user/2007-01/msg00052.html

     Pure event-driven systems have their uses, but you have to do
everything their way to get their advantages.  That's why they are
inherently frameworks, not libraries.

     Mixing multiple event-driven systems is non-trivial.  Usually,
you have to have a thread for each, and have them put events on
each other's queues.  Most event-driven frameworks aren't designed
for that. (QNX Photon is an exception; I had to integrate events
from USB devices, the GUI, and networks in a hard real time application,
and the correct locking mechanisms had been provided to do that.)

     ASIO seems to be based on the assumption that everything the
program needs to wait for can be expressed with a socket 'select' call.
When that's the case, everything is fine.  When it's not, it's
a bad fit.

     Having a standard C++ event driven model that covers all event
sources would resolve this problem.   If we had a standard library
that handled threads, events, and queues, and could support waiting
for events from all potential sources, we'd have a good base.
ASIO might be a starting point for that.

     But that's politically dangerous.  It would put the C++ committee
in the framework business, which makes it a competitor of Microsoft
for platform control.  Who controls the event loop controls the
platform.  Symantec, Borland, and Metrowerks all ran into that problem.

     But if it didn't incorporate a GUI, and could interoperate with
other event-driven systems, it could work.  This might provide a way
to think more clearly about threading models.  ASIO has some of the
right pieces, but there's too much hand-waving when threads come up.

     It's time to stop ducking concurrency.  If it isn't dealt with
well in the next C++ standard, the standard is irrelevant to the
era of CPUs with tens or hundreds of cores.

     John Nagle

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

John Nagle wrote:
.
>     It's time to stop ducking concurrency.  If it isn't dealt with
> well in the next C++ standard, the standard is irrelevant to the
> era of CPUs with tens or hundreds of cores.

Again, I bring up the Austria C++ alpha on
http://netcabletv.org/public_releases/.

There is an interface called an "Activity List".  It's the base class of
a thread pool.  An object can register to be called back by an activity
list at some future point in time.  If the class is written correctly,
it can use the library's activity list that is basically a thread pool,
however, you can easily tap into an event loop and write an event loop
based activity list with a single thread (the event loop's thread).
This would allow you to single thread where you need to.

I've used this on 2 different event loop frameworks so I know it can be
done.

There are some things that could be changed in the standard to make it
easier to use.  One of the things I like to see is that the activity
list/threadpool calls the method that I want called on the class, making
the code maintainable (without a switch statement).  There are a number
of mechanical things that need to be done to get this right, i.e. the
most derived class destructor needs to unqueue all activities of that
object off the activity list and to do this more easily, there are a few
other tricks involved that could be made cleaner if the standard
supported a few more concepts.

Without going into to much detail of the Austria C++ Activity List, I
think there is a need for something like this as part of the C++
standard and not just a simple thread pool thing.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

John Nagle wrote:
 > Mathias Gaunard wrote:
 >> asio *is* single thread with one main process loop.

Actually it's more correct to say that Boost.Asio supports use with a
single thread and main process loop. However, as I illustrated in one of
my earlier messages, that is certainly not the only way to use it.

 >     That's the problem.

Given my response above, I don't believe that is a problem.

 >     Consider that "Tk" is also single thread with one main
 > process loop.  As are most GUI libraries.  Now try to make
 > both play together.  It's not fun.
 >
 >     This is called the "duelling event loop scenario".  There's
 > a user discussion of this at
 >
 >     http://osdir.com/ml/lib.boost.asio.user/2007-01/msg00052.html

If you read the thread closely you will see that it is about the thread
safety guarantees specified in the Boost.Asio documentation. The use of
a separate thread to run an io_service as part of a GUI is just the
context. It is a perfectly valid design choice, and one that is
successfully used in GUI applications that utilise Boost.Asio.

 >     Pure event-driven systems have their uses, but you have to do
 > everything their way to get their advantages.  That's why they are
 > inherently frameworks, not libraries.

As I mentioned before, Boost.Asio supports more than just pure
event-driven systems. That is why I strongly disagree with your
assertion that it is a framework.

 >     Mixing multiple event-driven systems is non-trivial.  Usually, you
 > have to have a thread for each, and have them put events on each
 > other's queues.  Most event-driven frameworks aren't designed for
 > that. (QNX Photon is an exception; I had to integrate events from USB
 > devices, the GUI, and networks in a hard real time application, and
 > the correct locking mechanisms had been provided to do that.)
 >
 >     ASIO seems to be based on the assumption that everything the
 > program needs to wait for can be expressed with a socket 'select'
 > call. When that's the case, everything is fine.  When it's not, it's a
 > bad fit.

I understand this to mean that you are saying that Boost.Asio must take
over control of a program using a single event loop based around
'select'. This sounds like you are just restating your position that
Boost.Asio must be "in charge of all the threads". And as I said before,
this is certainly not the case.

Of course, Boost.Asio is already in use in programs that wait on things
other than sockets.

 >     Having a standard C++ event driven model that covers all event
 > sources would resolve this problem.   If we had a standard library
 > that handled threads, events, and queues, and could support waiting
 > for events from all potential sources, we'd have a good base.
 > ASIO might be a starting point for that.
 >
 >     But that's politically dangerous.  It would put the C++ committee
 > in the framework business, which makes it a competitor of Microsoft
 > for platform control.  Who controls the event loop controls the
 > platform.  Symantec, Borland, and Metrowerks all ran into that
 > problem.

Let's be clear about the scope of my proposal: it's a networking
library. Existing development practice in networking ranges from
thread-per-connection to highly scalable asynchronous I/O designs.
Boost.Asio is used to address these sorts of use cases.

For example, the asynchronous aspects of Boost.Asio on Microsoft Windows
are thin wrappers around overlapped I/O and I/O completion ports. Where
a program currently uses a thread to process I/O completions via this
native API, that thread can be used to invoke Boost.Asio completion
handlers instead.

In addition to Windows overlapped I/O, Boost.Asio is similar to (and in
some ways based on) existing practice in socket APIs on other operating
systems, such as POSIX AIO, the Extended Sockets API, Solaris 10 event
ports, and the Symbian and .NET socket classes.

 >     But if it didn't incorporate a GUI, and could interoperate with
 > other event-driven systems, it could work.  This might provide a way
 > to think more clearly about threading models.  ASIO has some of the
 > right pieces, but there's too much hand-waving when threads come up.

Exactly what "hand-waving" are you referring to?

Cheers,
Chris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hi James,

James Kanze wrote:
 > Just curious, but "no work left" means what?  My vision of this
 > (perhaps mistaken) is that of a server, which is up 100% of the
 > time, waiting for connections.

"Work" typically means an outstanding asynchronous operation. In a
server that is waiting for connections, but has no current connections,
this work would be the outstanding accept operation. If the accept
operation completes and a new asynchronous operation is started then
there is still work. If no new operation is started then there is no
work left.

A simple example:

   void handle_accept()
   {
     // Do nothing.
   }

   ...

   my_acceptor.async_accept(my_socket, boost::bind(handle_accept));
   my_io_service.run(); // Blocks until operation completes.

Cheers,
Chris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Tue, 17 Apr 2007 00:02:05 +0000, John Nagle wrote:
>> asio *is* single thread with one main process loop.
>> I don't understand your point.
>      That's the problem.
>      Pure event-driven systems have their uses, but you have to do
> everything their way to get their advantages.  That's why they are
> inherently frameworks, not libraries.

Agreed.

>
>      Mixing multiple event-driven systems is non-trivial.

I am grappling with this problem right now. I have been working on a
program that has to employ two event loops and there isn't even a GUI
involved. One loop considers itself to be part of a framework, the other
is from a library that tries to hide the event loop by putting it into a
separate thread. The lib means that the app writer needs to know there is
this other thread and has to make it cooperate with his thread of control

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andrew Marlow wrote:
> On Tue, 17 Apr 2007 00:02:05 +0000, John Nagle wrote:
>
>>>asio *is* single thread with one main process loop.
>>>I don't understand your point.
>>
>>     That's the problem.
>>     Pure event-driven systems have their uses, but you have to do
>>everything their way to get their advantages.  That's why they are
>>inherently frameworks, not libraries.
>
>
> Agreed.
>
>
>>     Mixing multiple event-driven systems is non-trivial.
>
>
> I am grappling with this problem right now. I have been working on a
> program that has to employ two event loops and there isn't even a GUI
> involved. One loop considers itself to be part of a framework, the other
> is from a library that tries to hide the event loop by putting it into a
> separate thread. The lib means that the app writer needs to know there is
> this other thread and has to make it cooperate with his thread of control

    I was just looking at some code where I had to deal with that problem.
In a control system for a large robot vehicle, we had a user interface
program with 1) a GUI, 2) a network connnection to the vehicle, 3)
a stall timer which had to be reset every 100ms to avoid an emergency
stop, and 4) inputs from a USB steering wheel and pedals, including
hot-plugging events.

    Three parts of the system had their own event loops - the GUI
(QNX Photon), the stall timer (run by a real-time timed loop that
checked system status), and the USB user interface device library
(which tried to follow Microsoft's callback conventions, even though that
wasn't really necessary on QNX.)

    What made this workable was that Photon had clear, documented
rules on locking.  Another thread could temporarily lock the Photon
library, which guaranteed that no Photon-owned object would be called
by a Photon thread. While locked, many Photon object methods could
be called by external threads. For example, you can change the value of
any GUI widget from a non-Photon thread.

    A set of rules like that makes ownership of an event loop much
more tractible in multi-threaded programs.  The capabilities needed
are 1) the ability to temporarily lock out the threads of an event
loop system, and 2) clear documentation of what methods can be
called from threads outside the event loop.  Event loop systems with
those properties play well with others.

    Any event loop system accepted into the C++ library should have
those properties.

     John Nagle

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

John Nagle wrote:
>     Generally, the Standard C++ libraries have been careful to adhere
> to a "library" model, where user code calls libraries, rather than a
> "framework" model, where the library calls user code.  This should
> continue.

However, I tend to think of function objects as some kind of callback
that is already existing in the standard library. I think passing a
custom strict weak ordering to sort() as an object is more intuitive and
useful than providing the building blocks for a custom sort algorithms
just to stick with the library paradigm.

Best regards,
Malte

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Malte Clasen wrote:
> John Nagle wrote:
>
>>     Generally, the Standard C++ libraries have been careful to adhere
>> to a "library" model, where user code calls libraries, rather than a
>> "framework" model, where the library calls user code.  This should
>> continue.
>
>
> However, I tend to think of function objects as some kind of callback
> that is already existing in the standard library. I think passing a
> custom strict weak ordering to sort() as an object is more intuitive and
> useful than providing the building blocks for a custom sort algorithms
> just to stick with the library paradigm.

     Sorting doesn't impose an event-driven structure on the whole program.
A callback-oriented communications structure does.

     John Nagle

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 11, 4:08 am, malte.cla...@arcor.de (Malte Clasen) wrote:
> John Nagle wrote:
> >     Generally, the Standard C++ libraries have been careful to adhere
> > to a "library" model, where user code calls libraries, rather than a
> > "framework" model, where the library calls user code.  This should
> > continue.

> However, I tend to think of function objects as some kind of callback
> that is already existing in the standard library. I think passing a
> custom strict weak ordering to sort() as an object is more intuitive and
> useful than providing the building blocks for a custom sort algorithms
> just to stick with the library paradigm.

I think his objection was to an asynchronous callback.  (I'm not
familiar with boost.asio, but that's what the name suggests.)
There'a big difference between a callback that is called from
within the function, and one which is called asynchronously,
some time later.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

James Kanze wrote:
> On Apr 11, 4:08 am, malte.cla...@arcor.de (Malte Clasen) wrote:
>
>>John Nagle wrote:
>>
>>>    Generally, the Standard C++ libraries have been careful to adhere
>>>to a "library" model, where user code calls libraries, rather than a
>>>"framework" model, where the library calls user code.  This should
>>>continue.
>
>
>>However, I tend to think of function objects as some kind of callback
>>that is already existing in the standard library. I think passing a
>>custom strict weak ordering to sort() as an object is more intuitive and
>>useful than providing the building blocks for a custom sort algorithms
>>just to stick with the library paradigm.
>
>
> I think his objection was to an asynchronous callback.  (I'm not
> familiar with boost.asio, but that's what the name suggests.)
> There'a big difference between a callback that is called from
> within the function, and one which is called asynchronously,
> some time later.

     Yes, that's right.

     The basic concept of Boost's "asio" is that "boost::asio::demuxer::run()"
owns the main event loop and calls everything else. That's a framework, not a
library.

     Frameworks tend to take over the program design.  Try using "asio".
and some GUI framework which also wants to own the event loop, in the
same program.  Sometimes multiple frameworks can be made to play together
using multiple threads, but it's usually not easy.

     That's why I'd argue against including something like "asio" in the
Standard C++ library.  There's nothing wrong with creating frameworks,
but they're not library components.

     John Nagle

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 10, 8:56 pm, John Nagle <n...@animats.com> wrote:

>      Once you start using a callback-based framework, you have to do
> everything that can delay via that framework.  Otherwise you stall the
> callback engine.  So the introduction of a callback-based framework
> determines the overall design of the program.

An obvious solution is to run the whole engine in its own thread.
However, doing so automatically would reduce the user's control, who
couldn't choose on which thread (or pool of threads) he wants to run
it on.
As far as I can see, the POSIX asynchronous I/O interface works more
or less that way. You attach callbacks and those are called once the
work is finished, but you don't need to initiate a loop.

For asynchronous I/O, you either need a system that notice you once
the work is finished (proactor pattern), or a system which you can
query to know when it's ready for work (reactor pattern).
The proactor pattern is not only way easier to use, but also it can
take advantage of OS features like Windows overlapped I/O. And it can
be implemented on top of the reactor pattern, that some OSes (most
unices) have support for.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 11 abr, 15:49, "Mathias Gaunard" <loufo...@gmail.com> wrote:

> As far as I can see, the POSIX asynchronous I/O interface works more
> or less that way. You attach callbacks and those are called once the
> work is finished, but you don't need to initiate a loop.

The aiocb structure is required to have these members:

int             aio_fildes     File descriptor.
off_t           aio_offset     File offset.
volatile void  *aio_buf        Location of buffer.
size_t          aio_nbytes     Length of transfer.
int             aio_reqprio    Request priority offset.
struct sigevent aio_sigevent   Signal number and value.
int             aio_lio_opcode Operation to be performed.

Notice there isn't a void* handler data member to keep a callback
around.

AIO works as the "proactor pattern" you mention: you can poll call
aio_suspend on an array of aiocb objects to receive completion
notification.

--
 Pedro Lamar   o


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Mathias Gaunard wrote:
> On Apr 10, 8:56 pm, John Nagle <n...@animats.com> wrote:
>
>
>>     Once you start using a callback-based framework, you have to do
>>everything that can delay via that framework.  Otherwise you stall the
>>callback engine.  So the introduction of a callback-based framework
>>determines the overall design of the program.
>
>
> An obvious solution is to run the whole engine in its own thread.
> However, doing so automatically would reduce the user's control, who
> couldn't choose on which thread (or pool of threads) he wants to run
> it on.

     Then you have to address thread-safety issues.  If you want
to change "asio" list of work to do, and it has its own thread, how and
what do you lock?  "asio" would need a lock that's locked when
"asio" isn't in its waiting state.  That doesn't seem to have been
addressed.

    John Nagle

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

John Nagle wrote:
.
>     Yes, that's right.
>
>     The basic concept of Boost's "asio" is that
> "boost::asio::demuxer::run()"
> owns the main event loop and calls everything else. That's a framework,
> not a
> library.
>
>     Frameworks tend to take over the program design.  Try using "asio".
> and some GUI framework which also wants to own the event loop, in the
> same program.  Sometimes multiple frameworks can be made to play together
> using multiple threads, but it's usually not easy.
>
>     That's why I'd argue against including something like "asio" in the
> Standard C++ library.  There's nothing wrong with creating frameworks,
> but they're not library components.

What's all this phobia over call backs.

An event based model is congruous to a callback model.

In the latest (unreleased) version of Austria C++ - (alpha available
http://netcabletv.org/public_releases/), it contains a framework that
follows a callback paradigm.  I have not found that it limits anything
in any way. (The callback interfaces are called twins in the Austria C++
impl).

Please explain what exactly is limiting in your mind ?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 12, 5:32 am, "Pedro Lamar   o" <pedro.lama...@gmail.com> wrote:

> The aiocb structure is required to have these members:
>
> int             aio_fildes     File descriptor.
> off_t           aio_offset     File offset.
> volatile void  *aio_buf        Location of buffer.
> size_t          aio_nbytes     Length of transfer.
> int             aio_reqprio    Request priority offset.
> struct sigevent aio_sigevent   Signal number and value.
> int             aio_lio_opcode Operation to be performed.
>
> Notice there isn't a void* handler data member to keep a callback
> around.

It's in aio_sigevent.
aio_sigevent.notify_function

See http://www-128.ibm.com/developerworks/linux/library/l-async/index.html
for a simple tutorial.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 12, 6:50 am, gi3nos...@mariani.ws (Gianni Mariani) wrote:
> John Nagle wrote:
> >     Yes, that's right.

> >     The basic concept of Boost's "asio" is that
> > "boost::asio::demuxer::run()"
> > owns the main event loop and calls everything else. That's a
> > framework, not a library.

> >     Frameworks tend to take over the program design.  Try using "asio".
> > and some GUI framework which also wants to own the event loop, in the
> > same program.  Sometimes multiple frameworks can be made to play together
> > using multiple threads, but it's usually not easy.

> >     That's why I'd argue against including something like "asio" in the
> > Standard C++ library.  There's nothing wrong with creating frameworks,
> > but they're not library components.

> What's all this phobia over call backs.

Not against callbacks per se, but against asynchronous
callbacks.

> An event based model is congruous to a callback model.

Yes.  The problem, as he clearly said, is making several event
based models work together in a single application.

> In the latest (unreleased) version of Austria C++ - (alpha availablehttp://netcabletv.org/public_releases/), it contains a framework that
> follows a callback paradigm.  I have not found that it limits anything
> in any way. (The callback interfaces are called twins in the Austria C++
> impl).

> Please explain what exactly is limiting in your mind ?

He just did.  He objects to having a library component take over
the basic loop.

I'd have to agree with him there.

If the callbacks are based on a threading model; i.e. the event
control runs in its own thread, then you have to take into
account the fact that the user's callback may be (and probably
will be) called from a thread the user doesn't even know about,
and you have to provide a mechanism for the user to stop the
thread (which he doesn't know about) in order to ensure clean
shutdown.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

James Kanze wrote:
> On Apr 12, 6:50 am, gi3nos...@mariani.ws (Gianni Mariani) wrote:
>
>>John Nagle wrote:
>>
>>>    Yes, that's right.
>
>
>>>    The basic concept of Boost's "asio" is that
>>>"boost::asio::demuxer::run()"
>>>owns the main event loop and calls everything else. That's a
>>>framework, not a library.
>
>
>>>    Frameworks tend to take over the program design.  Try using "asio".
>>>and some GUI framework which also wants to own the event loop, in the
>>>same program.  Sometimes multiple frameworks can be made to play together
>>>using multiple threads, but it's usually not easy.
>
>
>>>    That's why I'd argue against including something like "asio" in the
>>>Standard C++ library.  There's nothing wrong with creating frameworks,
>>>but they're not library components.
>
>
>>What's all this phobia over call backs.
>
>
> Not against callbacks per se, but against asynchronous
> callbacks.
>
>
>>An event based model is congruous to a callback model.
>
>
> Yes.  The problem, as he clearly said, is making several event
> based models work together in a single application.

The Austria C++ timer class is an example.  You can create one or N of
these.  Register a timer (event) and it runs it's own little loop.
No-one ever needs to worry how it's implemented inside.

>
>
>>In the latest (unreleased) version of Austria C++ - (alpha availablehttp://netcabletv.org/public_releases/), it contains a framework that
>>follows a callback paradigm.  I have not found that it limits anything
>>in any way. (The callback interfaces are called twins in the Austria C++
>>impl).
>
>
>>Please explain what exactly is limiting in your mind ?
>
>
> He just did.  He objects to having a library component take over
> the basic loop.

I'm confused, I have run into this problem in older badly designed apps
but with my more recent work (last 5 years or so) I have not run into a
situation where it can't work.  That's why I'm asking for clarification
of exactly what the problem is because I don't think it's there.

>
> I'd have to agree with him there.
>
> If the callbacks are based on a threading model; i.e. the event
> control runs in its own thread, then you have to take into
> account the fact that the user's callback may be (and probably
> will be) called from a thread the user doesn't even know about,

and this is a problem because ?

> and you have to provide a mechanism for the user to stop the
> thread (which he doesn't know about) in order to ensure clean
> shutdown.

Ah, that's called a destructor.  Some programmers object to that and
want a special call, however I find that whenever I want to shut down I
also want to destuct and so the destructor is an excellent was to signal
a "thread" object to get out quick.  The destructor will wait for the
thread to exit before the object is truly destroyed.

Maybe I see this as a solved problem and I don't get it.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

It's on the proposal page, any news about it?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 9, 8:02 am, "Siddhartha Gandhi" <siddharthagandhi...@gmail.com>
wrote:
> It's on the proposal page, any news about it?

The latest proposal is the one based on boost.asio


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

===================================== MODERATOR'S COMMENT:
 Please delete moderation banners when replying.


===================================== END OF MODERATOR'S COMMENT
On Apr 9, 12:17 pm, "Mathias Gaunard" <loufo...@gmail.com> wrote:
> On Apr 9, 8:02 am, "Siddhartha Gandhi" <siddharthagandhi...@gmail.com>
> wrote:
>
> > It's on the proposal page, any news about it?
>
> The latest proposal is the one based on boost.asio
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-...@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html                     ]

Hah, yet another. But any news on the time frame of this?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Mathias Gaunard wrote:
> On Apr 9, 8:02 am, "Siddhartha Gandhi" <siddharthagandhi...@gmail.com>
> wrote:
>
>>It's on the proposal page, any news about it?
>
>
> The latest proposal is the one based on boost.asio

    That seems to be a gratuitous wrapper around well-understood
functionality.  It also introduces a framework-like callback
model, which is probably inappropriate for the C++ standard
library.

    If someone wants to do something useful in this area,
Python's "urllib" would be a better place to start.

    John Nagle


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 9 abr, 23:28, John Nagle <n...@animats.com> wrote:
> Mathias Gaunard wrote:
> > On Apr 9, 8:02 am, "Siddhartha Gandhi" <siddharthagandhi...@gmail.com>
> > wrote:
>
> >>It's on the proposal page, any news about it?
>
> > The latest proposal is the one based on boost.asio
>
>     That seems to be a gratuitous wrapper around well-understood
> functionality.  It also introduces a framework-like callback
> model, which is probably inappropriate for the C++ standard
> library.
>
>     If someone wants to do something useful in this area,
> Python's "urllib" would be a better place to start.

I've played with designs for exposing socket primitives in C++ in
various manners.

I used to think that the best approach was to hide, somehow, the
"primitive" functions and just expose wrapper classes like socket,
listener, selector, and the like. I figured this because <iostream>
doesn't expose anything.

But then there is this proposal of a threading library that sort of
standardize pthreads.

Is this the approach the committee would prefer?
A standardized <csocket> thing or something?

On a side note I've recently requested membership on the mailing list
of the "POSIX C++" working group. I want to ask this question to them
too.

--
 Pedro Lamar   o


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Apr 10, 4:28 am, John Nagle <n...@animats.com> wrote:

>     That seems to be a gratuitous wrapper around well-understood
> functionality.

I doubt the design of networking applications is that well understood,
especially asynchronous ones.
And I won't call asio gratuitous, since it is definitely a novative
design, way cleaner than ACE or similar older libraries.


>  It also introduces a framework-like callback
> model, which is probably inappropriate for the C++ standard
> library.

I don't see how it is inappropriate.
Callbacks is the cleanest way to handle asynchronous I/O, and the most
portable one.

Callbacks anyway are underused in the C++ standard library, there are
multiple places where you could use them for delayed evaluation,
delegating invocation, closures... They're a Good Thing.
I honestly don't see what your reluctance to callbacks is based on.

The point of this proposal is to provide a powerful, efficient, safe
and portable way to handle networking. Putting it in the standard
allows abstraction from the underlying environment.
And asynchronous I/O is important, unless you only want to make the
networking library a very limited subset of the OS functionality,
making lot of people people use the OS-specific libraries instead of
the standard one.


>     If someone wants to do something useful in this area,
> Python's "urllib" would be a better place to start.

That's not networking, but a much higher-level wrapper library that
works in the application layer and not the network or transport layer.
And to write that, you need the basic building blocks of low-level
networking anyway.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Mathias Gaunard wrote:
> On Apr 10, 4:28 am, John Nagle <n...@animats.com> wrote:
>
>
>>    That seems to be a gratuitous wrapper around well-understood
>>functionality.
>
>
> I doubt the design of networking applications is that well understood,
> especially asynchronous ones.
> And I won't call asio gratuitous, since it is definitely a novative
> design, way cleaner than ACE or similar older libraries.
>
>
>
>> It also introduces a framework-like callback
>>model, which is probably inappropriate for the C++ standard
>>library.
>
>
> I don't see how it is inappropriate.
> Callbacks is the cleanest way to handle asynchronous I/O, and the most
> portable one.
>
> Callbacks anyway are underused in the C++ standard library, there are
> multiple places where you could use them for delayed evaluation,
> delegating invocation, closures... They're a Good Thing.
> I honestly don't see what your reluctance to callbacks is based on.

     The basic problem with callback-based approaches is that they
tend to work only when there's only one of them.  That's why they're
more a "framework" feature than a "library" feature.  It's usually
very difficult to mix framework models.

     Generally, the Standard C++ libraries have been careful to adhere
to a "library" model, where user code calls libraries, rather than a
"framework" model, where the library calls user code.  This should
continue.

     Once you start using a callback-based framework, you have to do
everything that can delay via that framework.  Otherwise you stall the
callback engine.  So the introduction of a callback-based framework
determines the overall design of the program.

     That's why they don't belong in the standard library.

    John Nagle

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]