[boost] "[gsoc] Thread scheduler support for boost"

Subject: [boost] "[gsoc] Thread scheduler support for boost"
From: Indradip Ghosh (indraghosh2k_at_[hidden])
Date: 2009-03-25 05:43:16

Hi Phil and Mathias,

I completely appreciate the portability issues involved in making such
an extension in which case it has to come with a portability clause
and disclaimer which would become a deterrent in including such a
facility in the library.

However, I thought of your suggested extension of threadpool class
exploiting processor affinity techniques and it sounds very
interesting as well but I guess we would run into the same portability
issues with regard to availability of the lower level API exposing the
hooks to be able to develop such a facility. Another issue would be to
qualify and justify how much improvement would this type of
parallelism enable on top of the instruction level parallelism already
in place for all modern processors. Although, I would still like to
find out if you have any concrete lead in mind.

I know for sure that there are those hard engineering problems in high
performance computing domain to ensure QOS guarantees to distributed
real-time embedded systems. They look into processor utilization
optimizations in the face of uncertainty of computational load on the
system. These usually require some kind of mathematical validation of
the scheme for the system under construction. I guess that would be
beyond the scope of the GSOC project, given the time frame.

M:N type of models would also have the same portability issue as it
requires changing kernel code as well as the userland code in thread
library.

Please let me know if you can think of a any non trivial portable
addition that you can think of an I can work on it. In fact, I don't
mind doing a big project even if it goes beyond the time frame of GSOC
if we can see value in it. Please let me know.

Thanks,
Indradip.
____________________________________________________________________________
> From: Mathias Gaunard <mathias.gaunard_at_[hidden]>
> Subject: Re: [boost] "[gsoc] Thread scheduler support for boost"
> To: boost_at_[hidden]
> Message-ID: <gq97h5$dbk$1_at_[hidden]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Indradip Ghosh wrote:
>
>>  I would like to get suggestions on developing a thread scheduler API for
>>  supporting users having specific needs in prioritizing threads
>>  running on SMP / Multi-Core processors. Please let me know the
>>  viability of including such an API in generic boost distribution and
>>  whether anyone would volunteer to mentor this effort as a GSOC
>>  project.
>
> Are you suggesting a N:M threading model where you can specify the
> userland scheduler?
>
>
>
Hi Indradip,

I have previously looked at passing POSIX thread attributes (i.e.
priority and policy) and it's not much work; presumably it could now be
done using the native handle in the proposed std::thread and new
version of boost::thread.  How close to the POSIX semantics does
Windows come?  Boost generally prefers to implement portable stuff
(although that's not something I need!) and choosing to work in an area
where the different platforms have little common ground will make
things more difficult for you, unless you're already familiar with how
this stuff works on both POSIX and Windows systems.

Beyond that there's the area of processor affinity, where as far as I
know POSIX has nothing to say.  Linux has some APIs for this but I
doubt they have much in common with any other platforms.  Maybe the
Intel TBB library has already solved all of this?

I'm wondering how something like a thread pool would be extended to
exploit processor affinity, if the lower-level API offered it.

Do you have a motivating application?

Phil.

On Tue, Mar 24, 2009 at 5:09 AM,  <boost-request_at_[hidden]> wrote:
> Send Boost mailing list submissions to
>        boost_at_[hidden]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.boost.org/mailman/listinfo.cgi/boost
> or, via email, send a message with subject or body 'help' to
>        boost-request_at_[hidden]
>
> You can reach the person managing the list at
>        boost-owner_at_[hidden]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Boost digest..."
>
>
> The boost archives may be found at: http://lists.boost.org/MailArchives/boost/
>
> Today's Topics:
>
>   1. Re: Re quest interest in Bloom filters (Phil Endecott)
>   2. [asio] basic_datagram_socket::send_to (Miroslav Berani? ml.)
>   3. Re: Can a Boost library use a component like GMP and mfpr
>      that have a LGPL license ? (Simonson, Lucanus J)
>   4. Re: Can a Boost library use a component like GMP and mfpr
>      that have a LGPL license ? (Sebastian Redl)
>   5. Re: Can a Boost library use a component like GMP and mfpr
>      that have a LGPL license ? (Simonson, Lucanus J)
>   6. Re: Can a Boost library use a component like GMP and mfpr
>      that have a LGPL license ? (Sebastian Redl)
>   7. Re: Can a Boost library use a component like GMP and mfpr
>      that have a LGPL license ? (Simonson, Lucanus J)
>   8. Re: Can a Boost library use a component like GMP and mfpr
>      that have a LGPL license ? (Schrader, Glenn)
>   9. Re: Can a Boost library use a component like GMP and mfpr
>      that have a LGPL license ? (Mathias Gaunard)
>  10. [GSOC] 10 Day student application period begins today
>      (troy d. straszheim)
>  11. Re: How to build 32 bits boost library on a 64 bits platform
>      (Qihong Wang)
>  12. Re: "[gsoc] Thread scheduler support for boost" (Phil Endecott)
>  13. [interprocess] locked mutex and process killed (vicente.botet)
>  14. Re: "[gsoc] Thread scheduler support for boost" (Mathias Gaunard)
>  15. has_operator_new (Robert Ramey)
>  16. BOOST_NO_INTRINSIC_INT64_T (Robert Ramey)
>  17. Re: Can a Boost library use a component like GMP and mfpr
>      that have a LGPL license ? (Barend Gehrels)
>  18. Boost with ICU on AIX - Patch (solar_at_[hidden])
>  19. Re: has_operator_new (John Maddock)
>  20. Re: [interprocess] locked mutex and process killed (Edouard A.)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 23 Mar 2009 16:15:01 +0000
> From: "Phil Endecott" <spam_from_boost_dev_at_[hidden]>
> Subject: Re: [boost] Re quest interest in Bloom filters
> To: <boost_at_[hidden]>
> Message-ID: <1237824901397_at_[hidden]>
> Content-Type: text/plain; format="flowed"
>
> Vicente Botet Escriba wrote:
>> Phil Endecott-48 wrote:
>>>
>>> vicente.botet wrote:
>>>> I need for my application bloom filters. Do you know of a good boostified
>>>> generic implementation?
>>>> Is there any interest in such a generic bloom filters library in Boost?
>>>
>>> Hi Vicente,
>>>
>>> I have a simple generic Bloom filter here:
>>>
>>>      http://svn.chezphil.org/libpbe/trunk/include/bloom_filter.hh
>
>>> I seem to have lost the example code
>
> Now found and checked in here:
>
>     http://svn.chezphil.org/libpbe/trunk/examples/spellcheck.cc
>
>> The hard part (the hash functions) is left out quite elegantly. I was
>> thinking about defining some hash traits wich will allow the user to set the
>> hash functions in a independent way. Something like
>>
>> template <template T, size_t N> struct hash_traits;
>>
>> template <> hash_traits<SpecificUserType,0> {
>>     static unsigned hash(T& value) {
>>         // specific code
>>     }
>> }
>>
>> BTW, besides the tr1::hash function, are there other hash generic functions
>> in Boost?
>
> You can use Boost.CRC.  What sort of key do you have?  I once did some
> investigation of hash functions for strings for use with unordered
> containers; I was considering using a degenerate hash that only looks
> at the first N characters.
>
> Something I didn't mention before is that if you need, say, 10-bit hash
> values then a 32-bit CRC could give you three of them.  In this case
> your hash_traits would presumably compute the same CRC three times and
> extract different portions each time, which is not ideal.
>
>> I would need also the union and intersection functions. I'm wondering if
>> replacing the tr1::array by a boost::dynamic_bitset should make eassier
>> this.
>
> Well it's not exactly difficult with the array.  I've never used
> dynamic_bitset and being dynamic is not a requirement here.  I was
> concerned (as normal) about getting a fast implementation and the
> simple bit manipulation in my code is probably about as fast as you can get.
>
>
> Cheers,  Phil.
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 23 Mar 2009 17:54:14 +0100
> From: Miroslav Berani? ml. <miroslav.beranic_at_[hidden]>
> Subject: [boost] [asio] basic_datagram_socket::send_to
> To: boost_at_[hidden]
> Message-ID:
>        <c62cccb70903230954g7020c4c0w30664ae62556b6f_at_[hidden]>
> Content-Type: text/plain; charset=UTF-8
>
> Greetings,
>
> will method basic_datagram_socket::send_to flush data immediately to
> the endpoint or will first fill its internal buffer and than flush
> data to endpoint? I would like to make sure, data gets flushed to
> endpoint when this method is called.
>
> Is there any other way to flush data to endpoint?
> Does any socket::set_option(option); makes difference to behaviour of
> send_to method ?
> Why isn't it possible to set buffer size lower than 1024 (low-level
> restriction?), with method (basic_datagram_socket::send_buffer_size())
>
>
> There is no documentation about this.
>
>
> Best regards,
> -----
> Miroslav Berani? ml.
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 23 Mar 2009 09:58:20 -0700
> From: "Simonson, Lucanus J" <lucanus.j.simonson_at_[hidden]>
> Subject: Re: [boost] Can a Boost library use a component like GMP and
>        mfpr that have a LGPL license ?
> To: "boost_at_[hidden]" <boost_at_[hidden]>
> Message-ID:
>        <26E9B811E137AB4B95200FD4C950886B25DDF48C_at_[hidden]>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Sebastian Redl wrote:
>>>>
>>>> AFAICT, in the case of LPGPled libs such as GMP and MPFR, there is
>>>> no problem in using them in commercial products, even closed source
>>>> applications (provided a copy of the license is distributed with
>>>> said product), so I don't think there should be any restriction on
>>>> allowing Boost libs to depend on LPGL libs.
>>>
>>> The LGPL requires you to construct your code in such a way that you
>>> can relink with a new library.  It also requires you to allow users
>>> to reverse engineer the code for debugging.  Commercial users of
>>> Boost may not like those terms.
>>
>> My company, for example, would be interested in the BGL, but quite
>> unable
>> to include an LGPL library, since our copy protection mechanism kills
>> the application if it detects a debugger. This would be a license
>> violation. (We probably wouldn't need bignum functionality. As long
>> as the BGL can be used without the bignum libraries, we'd probably be
>> happy.)
>>
>
> Huh, they basically exclude copy protection in the terms of their license?  I didn't trust the LGPL when I read it because it was obviously written by a lawyer.  Did you mean GTL and type BGL by mistake?
>
> Ideally I'd like to eliminate dependence on big-num for robustness, for performance reasons if not license concerns, but this requires some fancy programming.  For instance, the degree-2 predicate of slope comparison requires 65 bits when the input is 32 bit coordinates.  That can be performed with 64 bit unsigned integer if you keep track of the sign seperately.  The only other places where I need high precision are the computation of the sweep-line intercept for comparing the y coordinates of segments that intersect the sweep-line and the actual computation of intersection points.  Instead of using mp rational I could provide robust calculations "by hand" if I implement enough of what is in a multi-precision rational to get by or come up with some tricks.  Long double only barely fails in my pseudo-exhasutive testing of line intersection computation.  Since its result is only off by a small margin I could potentially detect these errors and handle them specially.  The impor
>  tant aspect of the intersection computation is that when it snaps to the the integer grid both line segments must intersect that integer grid box.  This check can be performed with point on-above-or-below line segment based degree-2 predicates (on-above-or-below can be implemented with slope comparison) that don't need multi-precision or rationals and then I can search adjacent grid boxes for one that meets the criteria for correctness if the check fails for the one computed by floating point approximation.  Happily I have the ability to validate such fancy (read error-prone) code against the known correct big-num reliant implementation I already have.
>
> Luke
>
> ------------------------------
>
> Message: 4
> Date: Mon, 23 Mar 2009 19:01:29 +0100
> From: Sebastian Redl <sebastian.redl_at_[hidden]>
> Subject: Re: [boost] Can a Boost library use a component like GMP and
>        mfpr that have a LGPL license ?
> To: boost_at_[hidden]
> Message-ID: <49C7CE79.10607_at_[hidden]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Simonson, Lucanus J wrote:
>> Sebastian Redl wrote:
>>
>>> My company, for example, would be interested in the BGL, but quite
>>> unable
>>> to include an LGPL library, since our copy protection mechanism kills
>>> the application if it detects a debugger. This would be a license
>>> violation. (We probably wouldn't need bignum functionality. As long
>>> as the BGL can be used without the bignum libraries, we'd probably be
>>> happy.)
>>>
>>>
>>
>> Huh, they basically exclude copy protection in the terms of their license?
> They require that it is still possible to debug the LGPLed library in
> the context of the combined work. If there's a debugger killer as part
> of the copy protection (and every effective CP needs one), that's
> obviously not possible.
>>   I didn't trust the LGPL when I read it because it was obviously written by a lawyer.  Did you mean GTL and type BGL by mistake?
>>
> Yes. I typed BGL for Boost Geometry Library. Isn't one of the geometry
> libraries called that?
>> Ideally I'd like to eliminate dependence on big-num for robustness, for performance reasons if not license concerns, but this requires some fancy programming.  For instance, the degree-2 predicate of slope comparison requires 65 bits when the input is 32 bit coordinates.
> I'm fairly certain that I don't need that. So it's a question of how
> modular the library is.
>
> Sebastian
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 23 Mar 2009 11:16:01 -0700
> From: "Simonson, Lucanus J" <lucanus.j.simonson_at_[hidden]>
> Subject: Re: [boost] Can a Boost library use a component like GMP and
>        mfpr that have a LGPL license ?
> To: "boost_at_[hidden]" <boost_at_[hidden]>
> Message-ID:
>        <26E9B811E137AB4B95200FD4C950886B262115D3_at_[hidden]>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Sebastian Redl wrote:
>> Simonson, Lucanus J wrote:
>>> Sebastian Redl wrote:
>>>
>>>> My company, for example, would be interested in the BGL, but quite
>>>> unable to include an LGPL library, since our copy protection
>>>> mechanism kills the application if it detects a debugger. This
>>>> would be a license violation. (We probably wouldn't need bignum
>>>> functionality. As long as the BGL can be used without the bignum
>>>> libraries, we'd probably be happy.)
>>>>
>>>>
>>>
>>> Huh, they basically exclude copy protection in the terms of their
>>> license?
>> They require that it is still possible to debug the LGPLed library in
>> the context of the combined work. If there's a debugger killer as part
>> of the copy protection (and every effective CP needs one), that's
>> obviously not possible.
>>>   I didn't trust the LGPL when I read it because it was obviously
>>> written by a lawyer.  Did you mean GTL and type BGL by mistake?
>>>
>> Yes. I typed BGL for Boost Geometry Library. Isn't one of the geometry
>> libraries called that?
>
> I think it's called ggl, generic geometry library.  Boost geometry library would be confusing.
>
>>> Ideally I'd like to eliminate dependence on big-num for robustness,
>>> for performance reasons if not license concerns, but this requires
>>> some fancy programming.  For instance, the degree-2 predicate of
>>> slope comparison requires 65 bits when the input is 32 bit
>>> coordinates.
>> I'm fairly certain that I don't need that. So it's a question of how
>> modular the library is.
>>
> Well, I have no explicit dependency on big num, just provide the ability to override non-robust arithmetic by specifying a big num data type.  I have no direct code dependency on any external library, only the stl.
>
> What features of a geometry library do you need?  I'm always interested to know so that I can focus on the pieces that are (will be) used the most.  You can tell me off list if you prefer not to advertise this information.
>
> Thanks,
> Luke
>
> ------------------------------
>
> Message: 6
> Date: Mon, 23 Mar 2009 19:23:06 +0100
> From: Sebastian Redl <sebastian.redl_at_[hidden]>
> Subject: Re: [boost] Can a Boost library use a component like GMP and
>        mfpr that have a LGPL license ?
> To: boost_at_[hidden]
> Message-ID: <49C7D38A.8080506_at_[hidden]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Simonson, Lucanus J wrote:
>> What features of a geometry library do you need?  I'm always interested to know so that I can focus on the pieces that are (will be) used the most.  You can tell me off list if you prefer not to advertise this information.
>>
> It's pretty vague at this time. We've been doing without, and looking at
> it to optimize some algorithms that currently work on rasters. We're
> mostly looking for quickly doing many, many polygon intersections in a
> huge floating point coordinate system. (Transformed to integer rasters
> at a given resolution.) The whole thing is about geographic data.
>
> Sebastian
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 23 Mar 2009 11:30:38 -0700
> From: "Simonson, Lucanus J" <lucanus.j.simonson_at_[hidden]>
> Subject: Re: [boost] Can a Boost library use a component like GMP and
>        mfpr that have a LGPL license ?
> To: "boost_at_[hidden]" <boost_at_[hidden]>
> Message-ID:
>        <26E9B811E137AB4B95200FD4C950886B262115F7_at_[hidden]>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Sebastian Redl wrote:
>> It's pretty vague at this time. We've been doing without, and looking
>> at
>> it to optimize some algorithms that currently work on rasters. We're
>> mostly looking for quickly doing many, many polygon intersections in a
>> huge floating point coordinate system. (Transformed to integer rasters
>> at a given resolution.) The whole thing is about geographic data.
>>
> Do you need map overlay, or is polygon intersection enough?  I have both, but most other libraries only provide intersection.
>
> Luke
>
> ------------------------------
>
> Message: 8
> Date: Mon, 23 Mar 2009 14:38:15 -0400
> From: "Schrader, Glenn" <gschrad_at_[hidden]>
> Subject: Re: [boost] Can a Boost library use a component like GMP and
>        mfpr that have a LGPL license ?
> To: "boost_at_[hidden]" <boost_at_[hidden]>
> Message-ID:
>        <57F5948627B03042A29E70F4AABB446A9311073C9D_at_LLE2K7-BE01.mitll.ad.local>
>
> Content-Type: text/plain; charset="us-ascii"
>
>
>
>> -----Original Message-----
>> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
>> On Behalf Of Sebastian Redl
>> Sent: Monday, March 23, 2009 2:01 PM
>> To: boost_at_[hidden]
>> Subject: Re: [boost] Can a Boost library use a component like GMP and mfpr
>> that have a LGPL license ?
>
>> >
>> > Huh, they basically exclude copy protection in the terms of their
>> license?
>> They require that it is still possible to debug the LGPLed library in
>> the context of the combined work. If there's a debugger killer as part
>> of the copy protection (and every effective CP needs one), that's
>> obviously not possible.
>
> I assume you are referring to the "Combined Works" section of the LPGL. This is the only paragraph I can find containing the string "debug".
>
> *
> * 4. Combined Works.
> * You may convey a Combined Work under terms of your choice that,
> * taken together, effectively do not restrict modification of the
> * portions of the Library contained in the Combined Work and
> * reverse engineering for debugging such modifications, if you
> * also do each of the following:
> *
>
> The term "Library" means "the library that is licensed under the LGPL". Note that the wording says >debugging< and NOT a >debugger<. Debugging can be carried out in different ways. For instance, the library can be instrumented using printf/cout. While the ability to run a debugger is certainly convenient, I fail to see how this mandates it. Some may object to the reverse engineering clause but its only an issue if reverse engineering is actually needed. If you say up front how you use the library then there should be no need to reverse engineer anything.
>
>>
>> Sebastian
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
> ------------------------------
>
> Message: 9
> Date: Mon, 23 Mar 2009 19:51:31 +0100
> From: Mathias Gaunard <mathias.gaunard_at_[hidden]>
> Subject: Re: [boost] Can a Boost library use a component like GMP and
>        mfpr that have a LGPL license ?
> To: boost_at_[hidden]
> Message-ID: <gq8lnj$ii0$1_at_[hidden]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Sebastian Redl wrpte:
>
>>> Huh, they basically exclude copy protection in the terms of their license?
>> They require that it is still possible to debug the LGPLed library in
>> the context of the combined work. If there's a debugger killer as part
>> of the copy protection (and every effective CP needs one), that's
>> obviously not possible.
>
> In the case of DRM, the law in some countries requires to provide
> information for interoperability on demand anyway, so what the LGPL
> requires is actually required for any software in those countries.
>
>
>
> ------------------------------
>
> Message: 10
> Date: Mon, 23 Mar 2009 15:48:17 -0400
> From: "troy d. straszheim" <troy_at_[hidden]>
> Subject: [boost] [GSOC] 10 Day student application period begins today
> To: boost_at_[hidden]
> Message-ID: <49C7E781.1070600_at_[hidden]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> The window is open another week and a half or so.  Deadline: April 3.
>
> Our first student proposal (py3k support for boost python) arrived
> within moments of the start of the application period.
>
> Don't be shy, keep discussing your ideas, and make some proposals.  You
> can't get accepted if you don't apply.
>
> -t
>
>
>
> ------------------------------
>
> Message: 11
> Date: Mon, 23 Mar 2009 16:48:04 -0400
> From: Qihong Wang <qihongwang_at_[hidden]>
> Subject: Re: [boost] How to build 32 bits boost library on a 64 bits
>        platform
> To: boost_at_[hidden]
> Message-ID:
>        <cf7fc54c0903231348n7bb3b585k8ac4a71aabbb84d0_at_[hidden]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> It works for me. If I just specify address-mode, the library is still 64
> bits. I have to specify both. Before I tried this, I also tried to specify
> gcc version and compileFlag and linkFlag as -m32 according to document. That
> doesn't work either.
>
> Thanks Fr?d?ric and Alexander.
>
> On Mon, Mar 23, 2009 at 4:16 AM, Alexander Arhipenko <arhipjan_at_[hidden]>wrote:
>
>>  On Sat, Mar 21, 2009 at 10:58 PM, Qihong Wang <qihongwang_at_[hidden]>
>> wrote:
>> > Hello,
>> >
>> > My platform is a 64 bits Linux with gcc. My program needs to link a 32
>> bits
>> > library without source code and other
>> > libraries with source code. I wrote a script to build those libraries
>> with
>> > source code by
>> >
>> > ./configure --prefix=$install_prefix CFLAGS="-g -O2 -Wall -m32"
>> > CPPFLAGS=-m32 CXXFLAGS="-g -O2 -m32"
>> > make install
>> >
>> > Then start to build my executable through Makefile with -m32 flag either.
>> > The configure and make install work for other libraries but not work for
>> > boost. The boost libraries were compiled and
>> > installed but still 64 bits. Linker refused to link it. Is there any
>> simple
>> > approach to build 32 bits boost on 64 bits Linux?
>> >
>> > Thanks,
>> >
>> > Qihong
>> >
>>
>> Passing 'address-model=32 architecture=x86' arguments to bjam works fine
>> for me.
>>
>> Regards
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>
>
> ------------------------------
>
> Message: 12
> Date: Mon, 23 Mar 2009 21:05:06 +0000
> From: "Phil Endecott" <spam_from_boost_dev_at_[hidden]>
> Subject: Re: [boost] "[gsoc] Thread scheduler support for boost"
> To: <boost_at_[hidden]>
> Message-ID: <1237842306073_at_[hidden]>
> Content-Type: text/plain; format="flowed"
>
> Indradip Ghosh wrote:
>>  I would like to get suggestions on developing a thread scheduler API for
>>  supporting users having specific needs in prioritizing threads
>>  running on SMP / Multi-Core processors. Please let me know the
>>  viability of including such an API in generic boost distribution and
>>  whether anyone would volunteer to mentor this effort as a GSOC
>>  project.
>
> Hi Indradip,
>
> I have previously looked at passing POSIX thread attributes (i.e.
> priority and policy) and it's not much work; presumably it could now be
> done using the native handle in the proposed std::thread and new
> version of boost::thread.  How close to the POSIX semantics does
> Windows come?  Boost generally prefers to implement portable stuff
> (although that's not something I need!) and choosing to work in an area
> where the different platforms have little common ground will make
> things more difficult for you, unless you're already familiar with how
> this stuff works on both POSIX and Windows systems.
>
> Beyond that there's the area of processor affinity, where as far as I
> know POSIX has nothing to say.  Linux has some APIs for this but I
> doubt they have much in common with any other platforms.  Maybe the
> Intel TBB library has already solved all of this?
>
> I'm wondering how something like a thread pool would be extended to
> exploit processor affinity, if the lower-level API offered it.
>
> Do you have a motivating application?
>
>
> Phil.
>
>
>
>
>
> ------------------------------
>
> Message: 13
> Date: Mon, 23 Mar 2009 23:57:19 +0100
> From: "vicente.botet" <vicente.botet_at_[hidden]>
> Subject: [boost] [interprocess] locked mutex and process killed
> To: <boost_at_[hidden]>
> Message-ID: <D12CA6DE6C6E4902B1170C7ED7F2AD8D_at_viboes1>
> Content-Type: text/plain;       charset="iso-8859-1"
>
> Hi,
>
> what happens when a process owning interprocess::mutex is killed? is the mutex unlocked before the process dies?
>
> Thanks,
> Vicente
>
> ------------------------------
>
> Message: 14
> Date: Tue, 24 Mar 2009 00:55:18 +0100
> From: Mathias Gaunard <mathias.gaunard_at_[hidden]>
> Subject: Re: [boost] "[gsoc] Thread scheduler support for boost"
> To: boost_at_[hidden]
> Message-ID: <gq97h5$dbk$1_at_[hidden]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Indradip Ghosh wrote:
>
>>  I would like to get suggestions on developing a thread scheduler API for
>>  supporting users having specific needs in prioritizing threads
>>  running on SMP / Multi-Core processors. Please let me know the
>>  viability of including such an API in generic boost distribution and
>>  whether anyone would volunteer to mentor this effort as a GSOC
>>  project.
>
> Are you suggesting a N:M threading model where you can specify the
> userland scheduler?
>
>
>
> ------------------------------
>
> Message: 15
> Date: Mon, 23 Mar 2009 21:22:06 -0800
> From: "Robert Ramey" <ramey_at_[hidden]>
> Subject: [boost] has_operator_new
> To: boost_at_[hidden]
> Message-ID: <gq9n29$dr4$1_at_[hidden]>
>
> I've made a TRAK item to request a new type traits feature -
> has_operator_new.  I've included an implementation and a test - both
> type_traitsified.  Hope you can see fit to check it out, and if it's OK,
> check it in.  Let me know when you do this.  Once this is in,  I can clear a
> dependent feature request TRAK item from the serialization library.
>
> Robert Ramey
>
>
>
>
>
> ------------------------------
>
> Message: 16
> Date: Mon, 23 Mar 2009 21:38:54 -0800
> From: "Robert Ramey" <ramey_at_[hidden]>
> Subject: [boost] BOOST_NO_INTRINSIC_INT64_T
> To: boost_at_[hidden]
> Message-ID: <gq9o1p$fkm$1_at_[hidden]>
>
> boost config includes BOOST_NO_INTRINSIC_WCHAR_T.
>
> boost Is there any chance we might see BOOST_NO_INTRINSIC_INT64_T
> appear in the near future?
>
> Robert Ramey
>
>
>
>
>
> ------------------------------
>
> Message: 17
> Date: Tue, 24 Mar 2009 10:18:25 +0100
> From: Barend Gehrels <barend_at_[hidden]>
> Subject: Re: [boost] Can a Boost library use a component like GMP and
>        mfpr that have a LGPL license ?
> To: boost_at_[hidden]
> Message-ID: <49C8A561.7010709_at_[hidden]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi,
>
> Fernando Cacciola wrote:
>>
>> A different and much less ambitious goal could be to come up with a
>> good C++ *interface* to *those* libraries. That is, C++ number types
>> specifically designed to be implementable on top of a C API like that
>> of GMP and MPFR.
> This is the approach we planned to take. In our geometry library (GGL)
> we want to optionally calculate with large number types as GMP or CLN.
> The GGL (or other geometry libraries who might take the same approach)
> is completely independant from GMP and from their license. It can just
> work together.
>
> We will work this out in the upcoming preview of GGL. We realize that it
> is not applicable for geometry alone, so we make it independant from it
> and might submit it as a separate, small, header-only library. The
> sample (link below) shows a numeric_adaptor, having a policy of either
> gmp, or just ieee types, or other big number types as cln (not worked
> out). Other policies might elaborate adaptive precision.
>
> See
> http://geometrylibrary.geodan.nl/num/numeric_adaptor.html
>
> Details might change of course, such as the place of the member variable
> in either adaptor or policy, but the sample will give the general idea.
>
> Regards,
> Barend Gehrels, Amsterdam
> Bruno Lalande, Paris
>
>
>
>
>
>
> ------------------------------
>
> Message: 18
> Date: Tue, 24 Mar 2009 09:08:19 +0100 (CET)
> From: solar_at_[hidden]
> Subject: [boost] Boost with ICU on AIX - Patch
> To: boost_at_[hidden]
> Message-ID: <20090324080819.1361134C4B8_at_[hidden]>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> Hi there,
>
> while trying to get Boost 1.34.1 to work on an AIX machine, I
> found a bug that still persists in 1.38.0. You might want to fix
> this...
>
> In boost/regex/icu.hpp:
>
> 314c314
> <    typedef std::vector<UCHAR32> vector_type;
> ---
>>    typedef std::vector<UChar32> vector_type;
> 318,319c318,319
> <       v.push_back((UCHAR32)(*i));
> <       ++a;
> ---
>>       v.push_back((UChar32)(*i));
>>       ++i;
>
> It should be obvious once you look at the source environment -
> the UCHAR32 is probably a typo, and the ++a is copy-and-paste
> work. This has obviously never been test-compiled on a real
> machine. Surprising that this has not been caught earlier (since
> it's been in there since 1.33)...
>
> Anyway, with that patch (and a backport of another one on
> vacpp.jam that's been included in later versions of Boost), v1.34.1
> compiles cleanly with ICU-support on AIX.
>
> Regards,
>
> Martin Baute
>
>
>
>
>
> ------------------------------
>
> Message: 19
> Date: Tue, 24 Mar 2009 09:52:36 -0000
> From: "John Maddock" <john_at_[hidden]>
> Subject: Re: [boost] has_operator_new
> To: <boost_at_[hidden]>
> Message-ID: <0993906E24C64887BD216A8DA04492EC_at_acerlaptop>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
>        reply-type=response
>
>> I've made a TRAK item to request a new type traits feature -
>> has_operator_new.  I've included an implementation and a test - both
>> type_traitsified.  Hope you can see fit to check it out, and if it's OK,
>> check it in.  Let me know when you do this.  Once this is in,  I can clear
>> a dependent feature request TRAK item from the serialization library.
>
> I'll look into it: did you test out the is_virtual_base in SVN type_traits
> Trunk BTW?
>
> John.
>
>
>
> ------------------------------
>
> Message: 20
> Date: Tue, 24 Mar 2009 11:08:59 +0100
> From: "Edouard A." <edouard_at_[hidden]>
> Subject: Re: [boost] [interprocess] locked mutex and process killed
> To: boost_at_[hidden]
> Message-ID: <04ab3291f101326aab20f6b7c4b7253b_at_127.0.0.1>
> Content-Type: text/plain; charset="UTF-8"
>
> On Mon, 23 Mar 2009 23:57:19 +0100, "vicente.botet"
> <vicente.botet_at_[hidden]> wrote:
>> Hi,
>>
>> what happens when a process owning interprocess::mutex is killed? is the
>> mutex unlocked before the process dies?
>
> After a quick look at the source code:
>
> inline void interprocess_mutex::lock()
> {
>   if (pthread_mutex_lock(&m_mut) != 0)
>      throw lock_exception();
> }
>
> The answer to your question is "an exception will be thrown" since the call
> will return "EOWNERDEAD".
>
> Generally speaking when a thread terminates while holding a mutex, the
> mutex is considered abandoned and shared resources protected by the mutex
> are in an undetermined state. Hope you like quantum physics. ;)
>
> --
>
> EA
>
>
> ------------------------------
>
> _______________________________________________
> Unsubscribe &amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
> End of Boost Digest, Vol 2497, Issue 1
> **************************************
>