November 2009 - Boost-users

[interprocess] Best practice question on shared resources.
by Moritz 01 Nov '09

01 Nov '09

Hi there, I am writing a "server" that is capable of communicating data to many "clients". Because I am implementing different communication modes (async, sync), I need special methods to lock and unlock a managed shared memory segment. My question is how to store the mutex, semaphore and managed_shared_memory segment information that are required in the lock and unlock methods. I see different approaches to implement this on client side. 1. Open the resources in the constructor of the client. Save pointers to the resources as members. So it is possible to access the resources in every method of the client class without opening them every time. The problem is that I do not recognize if the resources were closed because they only throw on opening (using linux). 2. Open the resources in the functions. That means I have to create the resource objects every time the function is called. So I have a chance to recognize if the resources have been removed. But I think this will create some useless overhead. Has anybody implemented something similar to this. How would you handle the shared resources? Thanks in advance Moritz Illustration: 1. class client { client() { _mtx = new boost::interprocess::named_mutex(...); } void lock() { _mtx.lock() } boost::interprocess::named_mutex * _mtx; }; versus 2. class client { void lock() { boost::interprocess::named_mutex mutex(...); mutex.lock() } };

1 0

Re: [Boost-users] building some boost libs for Windows ce
by Tom Aylesworth 01 Nov '09

01 Nov '09

> I want to build two libs, statechart and signals, for Windows CE using > MSVC 8.0. I have found suprisingly little info on how to accomplish this, > and I wonder if anyone has done this before and have any configuration > files I could refer to, to save some time (I really don't know much about > bjam)? We're not using statechart or signals, but we are using several of the other Boost libraries under Windows Mobile 5 with MSVC 9. Best info I found was here: http://cowo.supersized.org/archives/27-Compiling-BOOST-1.35.0-with-STLPort-… I had to make another change to use MSVC 9 but you shouldn't need to for 8. We're also using wcelibcex to provide C library routines that aren't provided by Microsoft. You may not need them for the statechart and signals libraries, but here's a link just in case: http://wcelibcex.sourceforge.net/ Thomas Aylesworth Senior Software Engineer RealityMobile http://www.realitymobile.com/

2 1

date_time O/S conversion routine limitation
by Zachary Turner 01 Nov '09

01 Nov '09

Hello list, Apologies for the cross-post, this originally went to the boost-users list a day or so ago but it got no responses, and then I also realized it was actually more appropriate here. Suppose I have a cross-platform agent that communicates with a server. Agent from platform X sends a message to the server which contains a date/time. Server sends a message to another agent running platform Y with the same date/time. In practice X/Y are always either windows/linux or linux/windows. The server always tells the agent which platform's native format the time is represented in, so there should be no problem. Ideally I'd like to write the following code: ptime time; if (msg.is_from_windows()) { time = from_ftime<ptime>(msg.time()); } else { time = from_time_t(msg.time()); } But this doesn't work because from_ftime<> is not defined on linux. If from_ftime<> is already templated on the FILETIME type, is there any reason it needs to be #ifdef'd out on non-windows platforms? I mean, a FILETIME is really just a uint64, can't the templated function also just operate on a boost::uint64_t? Zach

1 1