Are any of these bugs _really_ show stoppers?
There are 25 bugs in the Trac system which are marked as "showstopper". Are any of these really worth holding up the release for? (and if not, should we reclassify these bugs?) http://svn.boost.org/trac/boost/report/29 986 Problem building Python modules on boost 1.34.0 1215 Boost 1.34.1, mpl: Wrong workaround detection using MinGW32 (or.hpp, line #33)" 2411 bzip2_compressor does not work with filtering_istream,new,Bugs,Boost 1.37.0 2512 interval cosh: wrong result if interval contains 0 (but is not identical to [0,0]) 2513 rint not present in Visual Studio 2008 2164 locate_root wrong under CygWin 2797 Two problems with thread_specific_ptr 2255 Compilation error during arm cross compile - boost 1.36 2883 Boost::signals compile problem with GCC 3.4.5 2958 [patch] changes to make asio compile on vxWorks 2956 vxWorks POSIX quirks for date_time 583 Fixes for build on IBM pSeries for AIX and Linux 426 lambda vs pure virtual functions 3325 Limited support for mapping regions to specific addresses in Linux 738 Memory leaks with signal::connect? 3480 Build fails on Debian: 2.6.18-5-686-bigmem #1 SMP Tue Dec 18 22:34:10 UTC 2007 i686 GNU/Linux 3165 wrong project-config.jam generated for intel-linux 2955 [patch] recursive mutex impossible if pthread_mutexattr_settype not defined 1066 Patch to make Boost.Python compile on SunCC 2185 bjam hangs when building libs/python/examples/quickstart under MacOS X 3716 Application crash when using Boost.Python in a plug-in DLL for that application 3723 gzip_docompressor error - basic_array_source no putback member 2330 thread::interrupt() can be lost if condition_variable::wait() in progress 3735 thread_group::interrupt_all() is unreliable 2226 boost::thread 1.36.0 /clr Link Error LNK2022 Just asking.... -- Marshall P.S. I don't mind fixing 2512 and 2513 - and can do that for 1.43 if people don't want them in 1.42.
On Sun, Jan 24, 2010 at 6:04 PM, Marshall Clow <mclow.lists@gmail.com>wrote:
3325 Limited support for mapping regions to specific addresses in Linux
Defect 3325 - The impact of this defect is that I need to patch Boost.Interprocess before I can successfully use it. The patch is very simple indeed, hence it isn't a huge deal for me if it isn't fixed for 1.42. However since the fix is so simple, perhaps we can get a fix in for 1.43. I would be willing to send a patch if desired. Regards, Neil Groves
On Jan 24, 2010, at 10:30 AM, Neil Groves wrote:
I think that creating a patch and attaching it to the ticket can only help. ;-) https://svn.boost.org/trac/boost/ticket/3325 -- Marshall
El 24/01/2010 19:30, Neil Groves escribió:
Sorry for being so late, but I don't think it's a defect (and it's a showstopper because no other has reclaimed such functionality). MAP_FIXED is dangerous and isn't portable so if the desired address is already mapped the mapping should fail. If you want to use unix behavior you can always use munmap to unmap the desired address range and try that address. Best, Ion
I would not argue with a change in the priority. For my use case it is a show stopper since while I can mmap and pass the address. I cannot guarantee the mapping occurs at the address I supplied. There is a perfectly valid use case for mapping the same physical address multiple times that is frequently used in the implementation of high performance circular buffers. I therefore believe that there is not an option for me to retain the functionality present in the earlier versions of Boost.Interprocess, even by adding system calls in my code. There are only two options available to me to get my code to work. The first is to patch the library to allow MAP_FIXED, the other is to not use Boost.Interprocess. I greatly appreciate the library hence I would rather negotiate a change. I also appreciate that I am only the second developer to have hit this issue. I propose an opt-in facility to MAP_FIXED and would be happy to provide an implementation. Regards, Neil Groves
participants (3)
-
Ion Gaztañaga -
Marshall Clow -
Neil Groves