Hello Gottlob,
In this particular case the tool will be reviewed during the Boost.FSM review (if it will, since it's not for public use anyway), so including it in X-Files won't reduce the amount of reviews. On the other hand, if Boost.FSM is rejected but there is interest to this tool, I would gladly extract it to the X-Files project.
If your library gets accepted, LWCO is accepted as an implementation detail. AFAIK you need at least a fast-track review to make it a public thing (not sure that's what you want, though).
I don't like the idea of important and *exposed* items being 'accepted as an implementation detail'.
An init_once isn't an easy thing to write. When people review Boost.FSM are they going to take a close look at the 'once' implementation. Probably not. They are going to focus on the central items related to the stated purpose of the library.
This lightweight_once is not a public component and is not a part of Boost.FSM interface. No users will ever see it unless they dig into the library implementation. And I had no intent to make it public anyway - there is Boost.Thread implementation for that purpose. The only reason why I implemented it is that I want my library to be header-only. Therefore I don't see much sense in asking a separate review for something that is an implementation detail of some another library. The fact that I tried to make this detail general enough to be able to be reused somewhere else (e.g. in another library) doesn't mean that it is public.
However, I'd at least very much welcome a test suite for LWCO.
Unless carefully reviewed, all threading code has bugs. Even if tested. It is the nature of threaded code. It is *extremely* hard to test in such a way that all possible cases are tried.
Agreed. -- Best regards, Andrey mailto:andysem@mail.ru