- Boost - lists.boost.org

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

(no subject)
by darin＠bentspoon.com 30 Jan '04

30 Jan '04

1 0

RE: [boost] Re: Re: Boost.Thread : IO multiplexing
by Hurd, Matthew 30 Jan '04

30 Jan '04

> 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. Some process abstractions might be straight forward for "kill" signals and the windows equivalent. 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. The other thing I'd like to see is a substitutable framework, like the synch stuff I posted a while ago, where you can develop to a particular policy concept, for example a shareable mutex, then substitute a single threaded or null mutex or anything else in. ACE has had something similar for many years and it is straight forward. The current interface does not support such use AFAICT, hence the synch wrapper I use. I'd be happy to document and clean this up if there is interest. Regards, Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

4 4

:Guess_Toolset in build.bat failed for mingw. Failed even correctthis one. please help as well.
by Herbert Yu 29 Jan '04

29 Jan '04

Not sure now. I downloaded version 1.30.2 of boost. The build.bat file in {root}\tools\build\jam_src cannot work correctly with mingw as it says. First I have to add following to build.bat for it can guess mingw call :Test_Path gcc.exe if not errorlevel 1 ( set BOOST_JAM_TOOLSET=mingw set BOOST_JAM_TOOLSET_ROOT=%FOUND_PATH%..\ goto :eof) setlocal & endlocal It guess first? Should use my environment first! I have set both BOOST_JAM_TOOLSET and TOOLS! set TOOLS=mingw Set BOOST_JAM_TOOLSET=mingw Even build.bat can guess my mingw, it failed as following: execunix.c: In function `execcmd': execunix.c:214: warning: passing arg 3 of `spawnvp' from incompatible pointer type C:\DOCUME~1\hyu\LOCALS~1\Temp/ccKYiaaa.o(.text+0x12f):timestamp.c: undefined reference to `file_time' C:\DOCUME~1\hyu\LOCALS~1\Temp/ccKYiaaa.o(.text+0x2cd):timestamp.c: undefined reference to `file_archscan' C:\DOCUME~1\hyu\LOCALS~1\Temp/ccKYiaaa.o(.text+0x315):timestamp.c: undefined reference to `file_dirscan' C:\DOCUME~1\hyu\LOCALS~1\Temp/ccCOkaaa.o(.text+0x131c):builtins.c: undefined reference to `file_dirscan' gcc -o bin.mingwx86\jam -DNDEBUG -DOPT_HEADER_CACHE_EXT -DOPT_GRAPH_DEBUG_EXT -DOP T_SEMAPHORE -DOPT_FIX_TARGET_VARIABLES_EXT -DOPT_IMPROVED_PATIENCE_EXT -DYYSTACKSIZE=5000 -s -O3 -finline-functions -DMINGW command.c compile.c exp and.c glob.c hash.c hcache.c headers.c hdrmacro.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c execunix.c fileunix.c pathunix.c ...failed .cc bin.mingwx86\jam... ...failed updating 1 target... ...updated 2 targets... Can anyone help me? I am not on the list. Please reply to my email address as well. Thanks Herbert Yu

1 0

lightweight mutex for MacOS
by Martin Taylor 29 Jan '04

29 Jan '04

Hi I would like to put forward an implementation of a lightweight mutex for MacOS. I have tested it with shared_ptr_mt_test.cpp without problem. It's fairly short, so I hope you don't mind me posting it directly here for review. I should add also that I didn't really write this code (that's not a disclaimer - Howard Hinnant cooked it up after I asked the Codewarrior newsgroup for help!) Anyway, here's the code: #if __MACH__ #include <sched.h> #else #include <Multiprocessing.h> #endif namespace boost { namespace detail { class lightweight_mutex { private: volatile int a_; lightweight_mutex(lightweight_mutex const &); lightweight_mutex & operator=(lightweight_mutex const &); public: lightweight_mutex(): a_(0) { } class scoped_lock; friend class scoped_lock; class scoped_lock { private: lightweight_mutex & m_; scoped_lock(scoped_lock const &); scoped_lock & operator=(scoped_lock const &); void yield_thread() { #if __MACH__ sched_yield(); #else MPYield(); #endif } public: explicit scoped_lock(lightweight_mutex & m); ~scoped_lock() { m_.a_ = 0; } }; }; inline lightweight_mutex::scoped_lock::scoped_lock(lightweight_mutex & m) : m_(m) { register volatile int *p = &m_.a_; register int f; register int one = 1; asm { loop: lwarx f, 0, p cmpwi f, 0 bne- yield stwcx. one, 0, p beq+ done } yield: yield_thread(); goto loop; done: ; } } // namespace detail } // namespace boost Martin

6 14

Gmane archive problems
by Gennaro Prota 29 Jan '04

29 Jan '04

FYI, this is a notice that appears at the top of Gmane's homepage (http://gmane.org) ------------- Problems January 29th 2004: By mistake Gmane ran an expiry process last night, which means that most of the articles are gone from the spool. They are now being rescued from backup, but this process will likely take a few days. ------------------- Genny.

1 0