Boost logo

Boost Users :

From: Richard Brown (sac2dude_at_[hidden])
Date: 2008-01-31 15:23:02


Ion,

I have a server process and multiple client processes which
successfully share a managed_shared_memory vector as well as two message_queues.
All processes are 32-bit, and run under both Windows XP and 64-bit XP Server (using 32-bit Wow emulation).

However I am trying to take advantage of the Windows XP 64-bit
OS, so I have attempted to build the Server process as 64-bit, while leaving the client processes at 32-bit (unfortunately I'm stuck with some 32-bit libraries and cannot move the client processes to x64 at this time).

Both the server and clients (64 bit and 32 bit respectively) can see the shared memory file that
Interprocess creates, and my class members use fixed-sized
datatypes (__int32, __int64), but after walking some of the code it
became apparent that Interprocess is having issues with mixing the different processes.

 Example: message_queue::do_receive(block_t block,
                                                          void *buffer,
                                                          std::size_t buffer_size,
                                                         std::size_t &recvd_size,
                                                         unsigned int &priority,
                                                         const boost::posix_time::ptime &abs_time)

...
...
      //Thre is at least message ready to pick, get the top one
      detail::msg_hdr_t *top_msg = p_hdr->top_msg();

      //Paranoia check
      if (top_msg == 0) {
         throw interprocess_exception();
      }

      //Get data from the message
      recvd_size = top_msg->len;
      priority = top_msg->priority;
...
...

The contents of top_msg appear to be "shifted", such that "top_msg->len;" now returns a 0.

Obviously much of this is due to std::size_t being sized differently on the server process (at 64-bit) vs. the client (32-bit) processes. II thought of doing a bit of experimentation, whereby I could replace all instances of std::size_t in the library with something windows specific - like "unsigned __int64", but I have no idea if variations in data type size are the only issue. Should I give it a try or perhaps a different approach would be better?

Thanks,

Rich Brown

if (Nabble.searchterms != null && Nabble.searchterms.length > 0) {
        Nabble.hilt(Nabble.searchterms, Nabble.get("nabble.msgtxt15191825"));
}

<!--
if( Nabble.ads ) {
        Nabble.ads();
}
//-->

//Nabble.gquery = 'test';
//Nabble.topicDumpSearch = true;
if (Nabble.gquery!=null) {
        if (Nabble.topicDumpSearch) {
                Nabble.get('nabble.searchResults').innerHTML = '<h1>&nbsp;Other threads matching \"<strong>'+Nabble.gquery+'</strong>\":</h1>'+
                '<p style=\"margin-left: 3em;\">looking for matching threads...</p>';
                Nabble.loadScript('/forum/TopicDump$SearchJs.jtp?query='+encodeURIComponent(Nabble.gquery)+'&post=15191825');
                Nabble.setVar('prev',null);
        } else {
                Nabble.setVar('prev',
                        '<big><a id="nabble.prev_search" href="/forum/Search.jtp?query='+encodeURIComponent(Nabble.gquery)+'">Search Nabble for "<b>'+Nabble.gquery+'</b>"</a>'
                );
        }
}

if( Nabble.prev )
        Nabble.writeReturnToLink(Nabble.prev);


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net