headers
OvermindDL1 | 1 May 01:05
Picon

Re: boost coroutine status

On Thu, Apr 30, 2009 at 3:33 PM, Nat Goodspeed <nat <at> lindenlab.com> wrote:
>>> I looked at this library a few years ago before I wrote my own (for a
>>> windows system),
>
> I'm curious how you did that? Assembly code?

Yep, and a lot of scaffolding, it is not an easy-drop in thing, but it
ran fast and supported an Actor based programming model (which is what
I was going for, which means that 10k little coroutines may be a small
number in many cases, fibers choke and die).  A lot of work to program
a new coroutine, but it worked well.  Not something anyone else would
want to use though (although much of the scaffolding that had to be
repeated could be done using templates now that I know those well
enough know).

On Thu, Apr 30, 2009 at 3:33 PM, Nat Goodspeed <nat <at> lindenlab.com> wrote:
>>> and the big problem I saw with it was that it uses
>>> fibers on windows.  Fibers have this little problem, if you say you
>>> need, say, 20kb for the fiber stack, it still allocates as much memory
>>> as a thread uses (4megs by default I think), meaning if you try to
>>> create 10k of these little buggers, you run out of memory well before
>>> that.  Made this library rather worthless for my use.
>
> Heh, my own use case involves a far smaller number of coroutines, so this
> isn't such a problem from my POV.

You should try the Actor Programming Model, pretend there is no global
state (unless you know for certain of no issues), create an atomic CAS
based scheduler to switch between the coroutines/actors, etc... It
scales well, works on multiple threads (with actors able to be
(Continue reading)

Permalink | Reply | 0 comments |
headers
tom fogal | 1 May 02:31

Re: Boost.MultiIndex question on merge

Ovanes Markarian <om_boost <at> keywallet.com> writes:
> On Thu, Apr 30, 2009 at 7:12 AM, tom fogal <tfogal <at> alumni.unh.edu> wrote:
> >
> > I find this very strange.  Gcc accepted some parallelized STL
> > implementation too in recent years, and I always questioned it.  For
> > example, 25.1.1/1 in c++98 (for_each def'n):
> >
> >  Effects: Applies f to the result of dereferencing every iterator in
> >           the range [first, last), starting from first and proceeding
> >           to last - 1.
> >
> > How could you possibly parallelize that?  It's defined to operate in
> > series.  I guess if the compiler could prove that `f' had no side
> > effects, and there were no volatiles involved, it might be possible (is
> > that strong enough to prove that that execution order is irrelevant?
> > hrm..)  It seems like the former would run up against solving the
> > aliasing problem, though.  What am I missing here?
> >
> > (Granted, I can't recall the last time I wrote a for_each that *relied*
> > on that execution order.  Further, I could probably be convinced that
> > requiring a particular ordering here was a specification mistake.
> > Still, a standard is a standard.)
> 
> my example was referring to find. There you use a single value to be
> found in the range.

You'll note that I said `For example'.  I did not claim that there
did not exist a std algorithm which could not be parallelized.  I
intended to claim that there exists some algorithms which can only
be meaningfully parallelized if one interprets the algorithm in a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tory Bjorklund | 1 May 04:26

Boost.Date_Time building for Windows CE

Hello,

My application builds fine when using Boost.Date_Time with win32 but when
building with a configuration for Windows CE I get the following errors:

boost/date_time/c_time.hpp(83) : error C2039: 'localtime' : is not a member
of 'std'
boost/date_time/c_time.hpp(83) : error C2660:
'boost::date_time::c_time::localtime' : function does not take 1 arguments
boost/date_time/c_time.hpp(92) : error C2039: 'gmtime' : is not a member of
'std'
boost/date_time/c_time.hpp(92) : error C2660:
'boost::date_time::c_time::gmtime' : function does not take 1 arguments
boost/date_time/gregorian/gregorian_io.hpp(12) : fatal error C1083: Cannot
open include file: 'locale': No such file or directory

Does anyone know how I may be able to build an app for CE that includes the
Date_Time library?

Thanks,

Tory
Permalink | Reply | 0 comments |
headers
A B | 1 May 06:00
Picon

Re: Overloading errors

I realize that it's impossible to know which function to call from
f(5) in the code I posted, but I get an error even if remove the
default value for the boolean in the second call, in which case it's
pretty clear which function I am calling. Any thoughts? Thanks.

On Fri, Apr 17, 2009 at 5:25 PM, A B <python6009 <at> gmail.com> wrote:
> Does anyone know why the following sample fails (it was adapted  from
> the boost overloading example) and how to do this correctly. Thanks in
> advance.
>
>
>
>
> #include <boost/python/module.hpp>
> #include <boost/python/def.hpp>
> #include <boost/python/args.hpp>
> #include <boost/python/tuple.hpp>
> #include <boost/python/class.hpp>
> #include <boost/python/overloads.hpp>
> #include <boost/python/return_internal_reference.hpp>
>
> using namespace boost::python;
>
> struct X
>
> {
>
>     int f(int x, double y = 4.25, char const* z = "wow")
>
>     {
(Continue reading)

Permalink | Reply | 1 comment |
headers
ZouLei | 1 May 06:22
Picon

What does "RALL-style" means ?

Hi, everyone.

When I refer the document of thread library, a word “RALL-style” appear in the introduction of the class lock_guard: This provides simple RAII-style locking of a Lockable object, to facilitate exception-safe locking and unlocking.

I didn’t got the main point of this word “RALL-style”, could anyone tell me the meaning ? Thanks.

Best wishes.

_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Permalink | Reply | 4 comments |
headers
Steven Watanabe | 1 May 07:19
Picon

Re: Overloading errors

AMDG

A B wrote:
> On Fri, Apr 17, 2009 at 5:25 PM, A B <python6009 <at> gmail.com> wrote:
>> struct X
>> {
>>     int f(int x, double y = 4.25, char const* z = "wow");
>>     int f(int x, bool b = true);
>> };
>>
>> <snip>
>>
>>     class_<X>("X", "This is X's docstring")
>>
>>         .def("f1", &X::f,
>>     

The compiler can't figure out which overload of X::f you mean.
It must be resolved here and there is not enough information.

>> <snip>
>>
>> g++ -fpic -shared -o test.so test.cpp -lpython2.4 -lboost_python
>> -I/usr/include/python2.4
>>
>> test.cpp: In function ‘void init_module_args_ext()’:
>>
>> test.cpp:31: error: no matching function for call to
>> ‘boost::python::class_<X>::def(const char [3], <unresolved
>> overloaded function type>,
>> etc.)’
>>     

In Christ,
Steven Watanabe
Permalink | Reply | 0 comments |
headers
Benjamin Lau | 1 May 07:19
Picon

Re: What does "RALL-style" means ?

It's not RALL, it's RAII, i.e. Resource Acquisition is Initialization.

Wikipedia has a reasonable treatise on it: http://en.wikipedia.org/wiki/RAII

Benjamin
Permalink | Reply | 1 comment |
headers
Steven Watanabe | 1 May 07:24
Picon

Re: What does "RALL-style" means ?

AMDG

ZouLei wrote:
> When I refer the document of thread library, a word "RALL-style" appear in
> the introduction of the class lock_guard: This provides simple RAII-style
> locking of a Lockable object, to facilitate exception-safe locking and
> unlocking. 
>
> I didn't got the main point of this word "RALL-style", could anyone tell me
> the meaning ? Thanks.
>   

It's RAII, not RALL, and it stands for Resource Acquisition Is 
Initialization.
I basically means that every resource, such as a lock, is owned by an object
whose destructor releases it.

In Christ,
Steven Watanabe
Permalink | Reply | 0 comments |
headers
Roman Shmelev | 1 May 09:51
Picon

Re: [asio] async write handler is not called until the socket is not closed

Ok, I made some investigation and found, that the situation is only
observed under high cpu loads.
Let's imagine one IO thread. on timer event (each second) it pushes X
messages to socket with async_write.
Also, at this time, the IO thread receives Y messages with async_read
through the same socket.
Is there any limit in pushing messages with async_write? What it is?

Windows XP sp2, boost 1.38.0

Thank you!
Permalink | Reply | 4 comments |
headers
Thomas Klimpel | 1 May 11:52

Re: performance of dijkstra_shortest_paths

> I recently ran into a situation where dijkstra_shortest_paths in
> the boost graph library was running very slowly.  When I replaced
> the call to dijkstra_shortest_paths with the code below, things were
> a couple of orders magnitude faster.  Any idea why?

Perhaps the code below doesn't compute the shortest paths? if the "queue" in the code below refers to
std::queue, it won't be a priority queue, but a first in first out queue. The priority queue would be std::priority_queue.

The important question is not whether the code below has this specific bug, but whether it gives the same
answer as dijkstra_shortest_paths for the input data where you observed dijkstra_shortest_paths to be
running very slowly (and still being a couple of orders magnitude faster). In that case, it would really be
interesting to find out why dijkstra_shortest_paths would be slower that the code below.

Regards,
Thomas
Permalink | Reply | 0 comments |

Gmane