Boost logo

Boost :

Subject: [boost] [thread] Minor memory leaks?
From: Gregory Peele ARA/CFD (gpeele_at_[hidden])
Date: 2009-03-26 12:14:54

I've been using Boost.Thread to implement an asynchronous task execution service, and when I run Valgrind I come across a fair number of reported memory leaks. Most of them are obviously my fault (there are some worker threads not being properly destroyed), but there are a few that I'm not clear from the stack trace whether or not they are under my control. Are there any known memory leaks in Boost.Thread?

The only thing that I've identified as a definite leak is in boost::this_thread::disable_interruption - it leaks 8 bytes from a TLS variable whenever it is constructed and destroyed by a non-Boost thread (at least on Linux.) This is obviously irrelevant for practical purposes, but I'm not sure if it's a good idea for something intended to implement a proposed C++ standard library to have known memory leaks.

Gregory Peele, Jr.
Applied Research Associates, Inc.

-----Original Message-----
From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On Behalf Of Joel Falcou
Sent: Thursday, March 26, 2009 12:00 PM
To: boost_at_[hidden]
Subject: Re: [boost] [gsoc] Interest check for 3d geometry proposal

Simonson, Lucanus J a écrit :
> It sounds to me like such a thing would need to employ archetecture
> specific techniques such as compiler intrinsics and inline-assembly to
> be in any way competitive in terms of performance with what probably
> exists in closed source development shops. Also, these things are best
> offloaded to the GPU if possible, and that code isn't written in C++.
simd intrinsic is actually enough but last time I proposed something on
those lines, it was dismissed as useless ....

Gpu are limited by the speed of the bus and you'll end up spending too
much time sending data back and forth.

Joel Falcou - Assistant Professor
PARALL Team - LRI - Universite Paris Sud XI
Tel : (+33)1 69 15 66 35
Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at