January 2014 - Boost-users - lists.preview.boost.org

Re: [Boost-users] [Asio] signal_set not blocking/queueing signals on shutdown (Slava)
by Marat Abrarov 16 Jan '14

16 Jan '14

> >> I've written an io_service+signal_set signal handling implementation > >> in a thread of my application that triggers an orderly shutdown when > >> (among other things) the user presses Ctrl+C. > >> > > I first hear about asio signals, but I believe purpose of these signal > facility in asio is only to help you to implement *waiting* for signals, > like SIGCHLD, or SIGUSR{12}, whateverer you may choose for your IPC > communication. You should not misuse asio for general signal handling. > Normally signals are instantaneous things to be delivered right now right > here without any regard in which state the target is. I personally agree with Benjamin and think that the main goal of asio::signal_set is to provide the Asio way to handle signals. Look at the Asio examples (http://www.boost.org/doc/libs/1_55_0/doc/html/boost_asio/examples/cpp03_exa mples.html) - the "HTTP Servers" series. They use asio::signal_set for the same goal/reason as Benjamin does. Regards, Marat Abrarov.

1 0

[Asio] signal_set not blocking/queueing signals on shutdown
by Benjamin Shadwick 16 Jan '14

16 Jan '14

I've written an io_service+signal_set signal handling implementation in a thread of my application that triggers an orderly shutdown when (among other things) the user presses Ctrl+C. According to the Boost.Asio documentation for signal_set ( http://www.boost.org/doc/libs/1_55_0/doc/html/boost_asio/reference/signal_s…), just having a signal_set (with inherent dependency on an io_service) with registered signals and not in a wait state is supposed to be enough to cause signals to be blocked/queued. After I stop the io_service and cancel the wait state on the signal_set, however, it appears that signal blocking/queueing is no longer occurring. I say this because hitting Ctrl+C during orderly shutdown after the io_service has stopped causes my application to instantly terminate (and in one case generate a core file). Is there something about stopping the io_service and/or canceling the async wait on the signal_set that is causing the note about signal queueing in the signal_set documentation to no longer apply? Thanks in advance.

2 2

[boost::shared_ptr] Easy to violate the One Definition Rule / C++11 / Check für standard used to compile Boost
by beet 15 Jan '14

15 Jan '14

Hi there, from what I can see, boost::shared_ptr has a different definition, depending on whether Boost is compiled in C++98 oder C++11 mode. For example, in C++11-mode, shared_ptr has a move-constructor. By default, however, Boost seems to be compiled in C++98 mode, even with a compiler like gcc 4.8 (Ubuntu 13.10 / 64 bit / Boost 1.55), that is perfectly capable of compiling in C++11 mode. So, while boost::shared_ptr is header-only, all Boost libraries that use boost::shared_ptr will assume the C++98 version. The build-environment of one of my applications checks the compiler (currently gcc and CLang) and, depending on the version, activates C++11 support, so that I can use some C++11-checks (such as override), that can easily be #defined away for C++98 . So what may happen here is that my main application uses a different boost::shared_ptr than the Boost libraries I want to link with. To me this seems to violate the one-definition rule (and may happen with other Boost libraries as well). Indeed I'm seeing some strange errors, where "if(!p) {raise_error();}" triggers for a shared_ptr<derived_class> p, but I can still access member functions of a base_class that derived_class is derived from. Now, while I'm not yet sure that the above is the cause of this problem, I'd like to make sure that my build system chooses the appropriate C++ standard for compilation. Hence: Is there any way I can check (e.g. through some #define provided by Boost) what C++ standard it has been compiled with ? Thanks and Best Regards, Beet

2 1

[Units] conversion between double and millimeter
by Richel Bilderbeek 15 Jan '14

15 Jan '14

Hello Boost.Units users, When I convert a double to a unit (e.g. meter) and back, this works as expected. When I convert a double to a prefixed unit (e.g. millimeter) and back, this fails to compile. The code below shows how I'd expect it to work. What do I overlook? Thanks, Richel Bilderbeek const double x_in_mm = 1.0; const Length x(x_in_mm * milli * meter); //This works as expected: const double x_again_in_m = x / meter; //Why doesn't this: const double x_again_in_mm = x / (milli * meter); //Fails

2 1

[log] Default logging configuration for trivial logger
by Ben Pope 15 Jan '14

15 Jan '14

Hi, I'm using the trivial logging interface, but I need to tweak the default configuration. I want to be able to flush after every log entry, and I also want to be able to do file rolling. As far as I can tell, in order to configure it this way, I pretty much need to configure the whole thing from scratch including formatters, but I can't find the code that sets up the default logger to replicate it. Any pointers? Cheers, Ben

1 0

boost.log: how to view open log files
by Georg.Kellerer＠lfu.bayern.de 14 Jan '14

14 Jan '14

Hi, currently i am writeng a windows service and use the boost.log library for logfile creation. The serive should run long and I want to view the log files when the service is running. At the moment the logfile is written to the disk when the service ends and the file always has a size of 0 bytes. Is there a way to configure boost.log in a way that the log entries are written to disk immideately and that the logfile is not locked for reading by another application so that I can view my logfile? Thanks a lot, Georg

3 3

Thread_group semantics
by Kenneth Adam Miller 14 Jan '14

14 Jan '14

When a thread_group is assigned a task using post, does that task get executed sequentially? Is there a list, so that, when too many posts are added to it, it keeps track of them?

3 11

[program-options] Line width ignored on add()-ed options_description?
by Rhys Ulerich 13 Jan '14

13 Jan '14

I've got a "primary" options_description instance to which I add() other "secondary" options_description instances. I want operator<< to print the primary and all secondary instances with the primary instance's line width. I expect that this should happen automagically because, after construction, I cannot adjust the private m_line_length member of the secondary instances through any public means. However, it does not. A small re-create follows my signature. In my applications, I do not control the construction of the secondary instances and so I cannot adjust the secondary instance's construction-time width setting. Is this behavior a deliberate design decision? Some minor rework to options_description::print(...) within src/options_description.cpp would make it possible. Thanks, Rhys #include <iostream> #include <boost/program_options.hpp> int main() { static const char lengthy[] = "123456789 123456789 123456789 123456789 " "123456789 123456789 123456789 123456789 " "123456789 123456789 123456789 123456789 " "123456789 123456789 123456789 123456789 " "123456789 123456789 123456789 123456789 " "123456789 123456789 123456789 123456789 " "123456789 123456789 123456789 123456789 "; boost::program_options::options_description foo(255); // Linewidth 255 foo.add_options() ( "foo", lengthy ); boost::program_options::options_description bar; // Default line width bar.add_options() ( "bar", lengthy ); // foo should either dictate bar's line width, or... // I should be able to change it via a public interface... // ... but I seemingly cannot. foo.add(bar); // Option --foo has a nice long width, // but option --bar is truncated. std::cout << foo; }

1 0

UDP bind problems
by ustulation 13 Jan '14

13 Jan '14

{Windows 7, MinGW 4.8, boost 1.55} I'm having some problems with UDP binds. I've a client that broadcasts datagrams for listeners listening on specific port and binds to a port itself if the listeners want to communicate something back. The port on which the client needs to bind is X and the servers are listening on Y. Problem: If I simulate a client-crash (eg., by causing segmentation fault by dereferencing a nullptr) after binding the UDP socket to the port, then once the client application is no longer running (no longer listed in Windows Task Manager) netstat -ano | find "X" still shows that someone is bound to port X and ip address of 0.0.0.0 (the client had specified the IP address as any address). The PID cannot be found in Windows Task Manager. However when I downloaded application TCPView I can see that a *<non-existent>* process is still bound to 50000. On starting the client (without making it crash this time) subsequently I get two behaviors: <1> On some machines the client is unable to bind to the socket again (although reuse_address option is set to true) and the error message is: An attempt was made to access a socket in a way forbidden by its access permissions. <2> On other machines the client binds successfully but the read handler is not called and the client does not receive any datagram on port X although the servers are unicasting to the client port X. Infact <2> is true even for launching multiple instances of the client on the same machine even if none of the clients were deliberately made to crash and exist as zombie processes. Only the 1st one gets datagrams. Here is how client socket is set up: if(!m_udpSocket.is_open()) { m_udpSocket.open(m_localEndpoint.protocol(), errorCode); //m_localEndpoint is address 0.0.0.0 and port X if(errorCode) { std::cerr << "Unable to open socket: " << errorCode.message() << std::endl; } else { m_udpSocket.set_option(boost::asio::socket_base::reuse_address(true), errorCode); if(errorCode) { std::cerr << "Reuse address option set failure. " << errorCode.message() << std::endl; } m_udpSocket.set_option(boost::asio::socket_base::broadcast(true), errorCode); if(errorCode) { std::cerr << "Socket cannot send broadcast. " << errorCode.message() << std::endl; } else { m_udpSocket.bind(m_localEndpoint, errorCode); if(errorCode) { std::cerr << "Socket cannot bind...!! " << errorCode.message() << std::endl; } } } } Can you explain why do I get <1> and <2> and what can I do to avoid them and make socket bind even if there is some other process bound to that socket? I need to support Windows, Linux and MAC -- View this message in context: http://boost.2283326.n4.nabble.com/UDP-bind-problems-tp4657731.html Sent from the Boost - Users mailing list archive at Nabble.com.

3 4

Fast IPC between Linux and Windows on the same host
by U.Mutlu 13 Jan '14

13 Jan '14

Hi, what is the fastest cross-platform IPC mechanism between Linux and Windows on the same physical host? Additional info: Host OS is Linux (Debian), Windows XP is hosted in VirtualBox. Of course TCP/IP sockets is a possibility, but I need something much faster. My preference would be to use shared memory, but is it possible in such an heterogene environment? And: can Boost.Interprocess be used for this scenario? Thx -- U.Mutlu DACOS Notdienstanlagen GmbH, Germany

4 6