- Boost - lists.boost.org

RE: [boost] Re: Re: Boost.Thread : IO multiplexing
by Darryl Green 30 Jan '04

30 Jan '04

> -----Original Message----- > From: Jeremy Maitin-Shepard [mailto:jbms@attbi.com] > Sent: Thursday, 29 January 2004 7:03 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Re: Boost.Thread : IO multiplexing > > > "Hurd, Matthew" <hurdm(a)sig.com> writes: > > >> On Behalf Of Sean Kelly > >> > >> What remains an issue in my mind is how far to take this. > Socket and > >> file classes for each platform at least... what else? > > > Waitable timers would be the other "main" one I'd guess. > > Unfortunately, I do not believe that it is possible to wait on both a > timer and a file descriptor on POSIX platforms, so this is the same > situation as mutexes (see below). It is easy enough to do this - for example see ACE's Reactor Notify for details. If you care about other threads you need the notify interface to force a wake-up when a new timeout needs to be calculated, otherwise just calculating the timeout parameter from the head of the timer queue before blocking is enough. > > > Some process abstractions might be straight forward for > "kill" signals > > and the windows equivalent. > > Signal handling abstraction is probably best done by a separate > library. Signals are useful for dealing with asynchronous > i/o on POSIX > platforms, but I would recommend that non-blocking, but not > asynchronous I/O be used by the library on those platforms. > > > I would still like to see mutexes, timers, socket i/o and > file i/o all > > with similar acquisition concepts so there is a hope of > marrying them > > down the track if it is not done up front. > > I believe it has been concluded that there is pretty much no > way at all > of efficiently waiting on both a mutex and a file descriptor on most > POSIX platforms, including Linux and BSD. Furthermore, it is also > inefficient on Windows, since it requires use of > WaitForMultipleObjects, which doesn't scale well. I would not > recommend that an i/o multiplexing attempt to handle mutexes and > timers. > I don't see why the library shouldn't be generic enough to allow a unification on a platform that supports it. It may not be all that mythical - I'm sure there was some discussion and patches on lkml some time back suggesting that it is possible to extend epoll to work with futexes. On the opposite side of the coin, Linux 2.6 has extended aio in the kernel that should make aio a pretty reasonable option for that platform and at least tries to address most of the negatives mentioned re using aio on Posix platforms. Haven't tried to actually use it yet though! Regards Darryl. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

3 2

Re: [Function] Implemented operator== and operator!=
by Raoul Gough 30 Jan '04

30 Jan '04

Raoul Gough <RaoulGough(a)yahoo.co.uk> writes: > <#part type="text/plain" filename="d:/TEMP/gcc_296_err.txt" disposition=attachment > description="g++ 2.96 compiler output"> > <#/part> I guess I don't know how to drive my news reader! Here's the error output as inline text: g++ -fPIC -ftemplate-depth-120 -w -DNDEBUG -O3 -DBOOST_PYTHON_MAX_BASES=2 -DBOOST_PYTHON_SOURCE -I/foo/boost -I/usr/local_cci/Python-2.2.1t/include/python2.2 -c -o boost/libs/python/src/converter/arg_to_python_base.os /foo/boost/libs/python/src/converter/arg_to_python_base.cpp /foo/boost/boost/function/function_template.hpp: In method `void boost::function0<R, Allocator>::assign_to (const boost::reference_wrapper<FunctionObj> &, boost::detail::function::function_obj_ref_tag) [with FunctionObj = void (*) (), R = void, Allocator = allocator<boost::function_base>]': /foo/boost/boost/function/function_template.hpp:427: instantiated from `boost::function0<R, Allocator>::assign_to (Functor) [with Functor = boost::reference_wrapper<void (*) ()>, R = void, Allocator = allocator<boost::function_base>]' /foo/boost/boost/function/function_template.hpp:289: instantiated from `boost::function0<R, Allocator>::function0 (Functor, typename boost::enable_if_c<boost::type_traits::ice_not<boost::is_integral<Functor>::value>::value, int>::type) [with Functor = boost::reference_wrapper<void (*) ()>, R = void, Allocator = allocator<boost::function_base>]' /foo/boost/boost/python/errors.hpp:29: instantiated from `boost::python::handle_exception (T) [with T = void (*) ()]' /foo/boost/boost/python/errors.hpp:36: instantiated from here /foo/boost/boost/function/function_template.hpp:511: Internal error #373. /foo/boost/boost/function/function_template.hpp:511: confused by earlier errors, bailing out scons: *** [boost/libs/python/src/converter/arg_to_python_base.os] Error 1 scons: building terminated because of errors. /bar/build % g++ --version g++ --version 2.96 -- Raoul Gough. export LESS='-X'

1 0

Re: [Function] Implemented operator== and operator!=
by Raoul Gough 30 Jan '04

30 Jan '04

<#part type="text/plain" filename="d:/TEMP/gcc_296_err.txt" disposition=attachment description="g++ 2.96 compiler output"> <#/part> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:mbn75GX0BrE0mKdP1bjMm9VxSrg= Douglas Gregor <gregod(a)cs.rpi.edu> writes: > On Tuesday 20 January 2004 01:29 pm, Douglas Gregor wrote: >> On the main branch, I've implemented operator== and operator!= for >> Boost.Function (but not in the form you expect). > > It's now documented. > > I've also checked in some changes to handle reference_wrapper logically: I just tried upgrading to the CVS mainline and got an internal compiler error in function_template.hpp when compiling one of the Python lib modules with gcc 2.96 linux. Reverting to RC_1_31_0 fixes the error. Recent lossage? /foo/boost/boost/python/errors.hpp:29: instantiated from `boost::python::handle_exception (T) [with T = void (*) ()]' /foo/boost/boost/python/errors.hpp:36: instantiated from here /foo/boost/boost/function/function_template.hpp:511: Internal error #373. /foo/boost/boost/function/function_template.hpp:511: confused by earlier errors, bailing out Compiler bug is documented at: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=57466 See attachment for more compiler output. -- Raoul Gough. export LESS='-X'

2 1

Graph: edge(u,v,g) isn't O(log(E/V)) as promised
by Alan Stokes 30 Jan '04

30 Jan '04

For an adjaceny_list which uses sets for its edges, edge(u, v, g) is supposed to be O(log(E/V)), as you would expect for a lookup in a set. (See http://www.boost.org/libs/graph/doc/using_adjacency_list.html#sec:choosing-….) But in fact it is linear in the number of out edges. This is because in graph/detail/adjacency_list.hpp (line 1325 in revision 1.113), in the edge_dispatch function that handles the disallow_parallel_edge_tag case, the code reads: i = std::find(g.out_edge_list(u).begin(), g.out_edge_list(u).end(), StoredEdge(v)), when it should probably be: i = g.out_edge_list(u).find(StoredEdge(v)), as it was in revisions 1.59 and previous. As an aside, it's not that obvious from the documentation that adjacency_list supports edge(u, v, g). AFAICT it's defined only in the AdjacencyMatrix concept, which adjacency_list is not documented as being a model of. [This is a repost - the original was in message 31695 on the 21st of January. But I foolishly reported two different problems with the same subject & in the same thread, only one of which was addressed. I'm assuming the other one was overlooked and so repeating it. I apologise if this assumption is incorrect.] - Alan

2 2

value_initialized added to libraries.htm
by Fernando Cacciola 30 Jan '04

30 Jan '04

Both on the main trunk and 1.31.0 RC2 Fernando Cacciola SciSoft

1 0

boost_1_31_rc2 - documentation glitches in tools/build/v2/
by Bronek Kozicki 30 Jan '04

30 Jan '04

1. GIF picture is corrupted: boost_1_31_0_rc2\tools\build\v2\c++boost.gif 2. two HTML files have bad "src" path to this picture: boost_1_31_0_rc2\tools\build\v2\doc\architecture.html boost_1_31_0_rc2\tools\build\v2\doc\extending.html B.

3 3

Who is the current maintainer of boost.thread?
by Roland 30 Jan '04

30 Jan '04

Some weeks ago Michael Glassford posted a question about the same subject. But as far as I can remeber without any answer. Did I miss something? Mike stated, that the original author silently disappeared from the list. The last relevant CVS commits have been done by a person named bill_kempf 11 months ago. Is this just a nickname for William Kempf? I like to restate the question, and also would offer to spend some of my time for helping in maintainance of the thread library. The submission_process.htm page also deals with Lifecycle, and says: "If you no longer can or wish to maintain your library, please post a message on the Boost developers mailing list and help someone else take over as the library maintainer." Does this also imply, that the only way to deal with an obviously silent maintainer, is to submit a totally new review request for a replacement library to move on with an otherwise stalled library? Regards, Roland

4 6

[graph] RC_1_31_0 bfs VC++ 7.1 failing metacomm only
by Beman Dawes 30 Jan '04

30 Jan '04

graph bfs VC++ 7.1 is passing on my machine but failing at runtime in Metacomm's tests. The only output is "EXIT STATUS: 666". Any ideas? --Beman

1 0

RE: [boost] Boost.Thread request: event object
by Sean Kelly 30 Jan '04

30 Jan '04

On Mon, 26 Jan 2004, Hurd, Matthew wrote: > > So are you saying that multiple threads calling WaitForSingleObject for > the same event is not safe or is the lack of safety elsewhere in the > windows event mechanism. I wouldn't mind a source url or something for > this if you have one so I can come up to speed. Aside from the papers linked to in the Boost.Thread documentation, the best thing to do is search comp.programming.threads for "windows" and "event." The discussion has come up there quite a few times, including some of the original talk about the Boost.Thread implementation. Alexander Terekhov (from this list) is involved in most of the discussions so you could search on his name as well. One such link is here: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=3e2ae910%240%245… By the way, I'm not saying that WaitForMultipleObjects is broken so much as that Windows events seem to be broken once you get beyond the fairly simple cases. Waiting on a mutex in Windows uses the WaitForObject calls as well, so I don't think the function itself is at issue. > I think WSFU if a crimson herring, best to forget about it. I don't think I'd ever want to require a customer to install WSFU to use my application, but from the documentation it seems quite solid. Rather than Win32 wrappers (ala Cygwin) it's actually an entire subsystem that contains a full posix implementation. I haven't done much more than skim the docs, but it's at least worth some play-time. As for the rest... I like to come to my own conclusions and an still reading up on the details in my rather limited free time. I will freely admit that I would be more likely to use the Boost condvar implementation everywhere rather than in just the complcated cases if I could safely do away with a large chunk of the code. I guess what I want is for someone to prove to me that the solution really does need to be as complex as it seems :) Sean

2 1

RE: [boost] Re: Re: Boost.Thread : IO multiplexing
by Darryl Green 30 Jan '04

30 Jan '04

> -----Original Message----- > From: Jeremy Maitin-Shepard [mailto:jbms@attbi.com] > I may be mistaken, but it seems that the new asynchronous I/O > completion system at least currently cannot be used with sockets. You are correct - I thought I saw a changelist somewhere that said otherwise but I must have been dreaming... Regards Darryl. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

1 0