Hi, the application which I'm working on is based on a client server architecture |java gui| <- gsoap -> |c++ server| where the server is a windows or unix program, which embeds the business logic. I want to make a gui for users, who don't need to know about that and simply start the gui as if it was the whole app. Thus the gui is managing server instantiation - gui started && server not running => gui starts server. gui started && server running => gui uses server. server has no more session within timeout => server exits gracefully. So what I actually would need is a singleton server and this would mean to query the OS for the existence of the server process. Java has no method to query process lists on a system independent level or to check, whether there is a certain process running - there's just rudimentary support for process control. Java is gui standard here. So I made a little app (nmmutex) which is supposed to control a named mutex for the server's main thread. This app exits always and writes it's result (acquired, not acquired) to the return code. The mutex is queried in a non-blocking manner (try_to_lock). Java can run that process via Runtime.exec. Using that mutex, the server itself may control, whether there is already an instance running. It also can try_to_lock the mutex, and if it's not available, may return. The server itself could also take the role of nmmutex, i.e. to query the mutex. The caveat of using the mutex is, as far as I understood, that boost interprocess objects like mutex and shared memory due to portability have 'kernel or filesystem' persistence. On windows it's filesystem persistence. So if the server crashes, it might not be restartable even after a reboot. And the user can't tell why. I tend to dislike the mutex idea meanwhile, although using it seemed logical to me first: I wanted to restrict use of server's main block to a single thread. I could try to get a soap session at gui startup and assume the server does not run when it fails. Or maybe there's a library which hides querys to the os, like process list, behind a portable interface. Cheers Werner

modified on Thursday, January 27, 2011 4:00 AM

Thank you, this I think is basically ok, but I would like the lock to be deleted, when the process, that created it crashes, which is not the case with a boost::named_mutex or a temp file, and on windows using such directories like temp and appdata a.s.o is always fuss, because they are rarely organised the same on all Windows NT systems and often not named the same and often not defined within the same system variable. If I had read the boost documentation before :| I had not been so surprised, that the mutex and the shm are opening a file because these objects have 'kernel or filesystem' persistence which on Windows seems to be always filesystem. Such objects need an explicit call to their remove function to remove the file. What I'm looking for is an interprocess object with process persistence. Cheers Werner

modified on Wednesday, January 26, 2011 6:46 PM

Thank you. Then I would hold the counter in a shared memory area. Which technique would you recommend for the shm? I would prefer one, which is platform independent to a high degree. I've experimented with the shared memory class in boost::interprocess. The boost shm object again seemed to create a file in the Application Data dir. I don't like this so much, because it is dependent on access restrictions to the fs.And this would not be necessary, because I'm just using ram. Werner

OS Version: Windows XP Pro boost Version: 1.44.0 Hi, I want to monitor, whether a certain process is running. The program of the process is written in C++ and is a console app. I've chosen the mutex concept, because I want to restrict usage of the program's main to exactly one thread. First I used the example from the boost site, which places the scoped_lock within the main routine's block. But when the app was terminated via the close button of the console window the scoped_lock destructor was not called which had a negative side effect: The mutex is associated with a file :| in the All Users\Application Data tree, directory boost_interprocess and if this file is not deleted, the mutex can not be acquired, although it is no more referenced by any application. Hence I wrapped the mutex into a global object (1) to instantiate it as soon as possible (2) to release it under as many circumstances of program termination as possible via the wrapper's destructor. This is the wrapper's class - you can see the mutex is non-blocking and controlled via a scoped lock struct ApplicationLock { ApplicationLock() : appmutex(open_or_create, "SilvaCoreMutex"), applock(appmutex, try_to_lock) {} bool alreadylocked() { return (applock == 0); } private: named_mutex appmutex; scoped_lock<named_mutex> applock; }; ApplicationLock appliclock; If the console window is closed, the desctructor is called and the mutex released. But if the process is terminated due to a crash or aborted via the task manager, the mutex is not released. Even a system restart doesn't release it. I thought a mutex should be held in a memory shared area and exclusively depend on this shared area and never depend on anything which is stored in the file system. How can I get rid of that mutex, when it is no more referenced by any application. Have I chosen the wrong concept? Have I misunderstood the boost mutex technique? Thanks in advance Werner

Hi, the process started by ProcessBuilder and by Runtime.exec - which is implemented via ProcessBuilder - is started asynchronously when the java app is started from jar. The effect of the frozen thread happened exclusively within the debbuger session. I should have tried. Sorry and thanks again Werner

Hi, I tried the same with process builder

    ProcessBuilder pbuilder = new ProcessBuilder(cmdlist);

    process = pbuilder.start();
    procmon = new ProcessMonitor(process);

where cmdlist[0] = "D:/MyPath/NmMutex" cmdlist[1] = "lock" (btw. this doesn't mean the main thread waits at lock, its try_lock) The thread returns as soon as the process, which was called ended. I tested it with a loop whithin the external process. If it is finite, the thread returns. If it is infinite the thread doesn't return. I.e. exec and start are blocking. The idea to call ProcessBuilder.start within a separate process is basically good, but I woudn't receive a process handle when start would not return. And without that, I would not be able to attach streams to the stdout and stderr. Hence the process might block as soon as the stdout and stderr buffers are filled up. If I started a background shell and within that my process, the solution would be os dependend (not KISS, complicated, not that good). Thanks Werner

It looks like that, although I'm much surprised, because this is not what Runtime.exec should do, when I read into the docs - ehm - assumed I understood them also. 1 might work, but you don't get the process handle, because calling thread is suspended before return from call 2 yes right, I think its worth trying because it seems to be more convenient thank you Werner

Hi, I'm new to using Runtime.getRuntime().exec on WindowsXP, JRE 6. Solution should work on all Windows NT from 5 upwards and common UNIX. I called it in the following way process = Runtime.getRuntime().exec(cmdargs); where cmdargs[0] = "D:\Somepath\NmMutex" cmdargs[1] = "lock" Program NmMutex with argument lock runs until its process is stopped externally. When Runtime.getRuntime().exec(cmdargs); is called, the calling thread remains suspended, until program NmMutex is killed. Is that the normal behaviour of Runtime.exec? I thought the calling thread would return, even if the program it started is still running, so I can observe the prog by reading its stdout and stderr from my Java app. If not it would return there would be no process created and I could not observe the program. Which way is best to solve that? Start prog in Background, like process = Runtime.getRuntime().exec("start /B NmMutex lock"); resp. process = Runtime.getRuntime().exec("& NmMutex lock"); ? Thank you Werner

Dear Adam, please refer to my answer to Eugen, thank you :) Werner

Dear Eugen, the diagnostic tool which I would find very useful would be one, which can show me something like

variable | chunk of heap start | chunk of heap end | length of heap | allocated by (method signature)
pFoo 0x00002000 0x20000000 536862720 heapcrusher

because I suspect, that the point in the program, where the exception happens is not the one which caused the trouble, but another, which caused a buffer overflow. Sometimes the app crashed at the end and signaled a segment fault. I also tried to debug the app as release version as you suggested but couldn't find out, why it crashed at the point, where it did. Do you know any which can do that? PS is it actually possible to see variable values in the debugger when I debug the release version? I thought there is no way. Thank you regards Werner

VC++ Windows XP Hi, I have to maintain a large application which sometimes crashes at the end. The cause is probably a buffer overflow somewhere: From time to time a system error message showed up which said that the code segment had been affected. I would like to find the source of the overflow but couldn't figure out where it could be. It only happens in the release version. I think this is due to the different initialization of debug memory with CD DD and so on. I think it would be easier, when I could run a debug session with heap and stack being initialized in the same way as in the release version. Is there any possibility to get that? Or is there a tool which can show me e.g.

slice of memory on the heap | origin routine | virtual addr begin | virtual addr end |
pFoo bar 0x00002000 0x20000000

Thank you Regards Werner

Dear Rajesh, I am very sorry, this happened automatically because in Germany marks at school are like that 1 = best, 6 = worst. I still can't get rid of that. Thank you very much and best regards Werner

I will do that. Thank you. Maybe I misunderstood the definition of implicit inline? I understood, that if a function is defined like that

class A
{
void someFunc()
{
// code
}
}

this is equivalent to

inline void A::someFunc()
{
// code
}

and I want it to be equivalent just to

void A::someFunc()
{
// code
}

Best regards Werner

Roger Stoltz wrote:

find these two conditions to be contradictory. In the first you want the compiler to decide, but in the second you don't want it to be automatic.... Confused Unsure

In the second I *want* it to be automatic. That's my point. The inline keyword, and I think implicit inline too, means, that you don't let the compiler be automatic but try to tell him what to do. This is what I *don't* want and would like to switch off. Regards Werner

I do agree. Tox's question was the most interesting answer to mine I found, and so I was much interested in discussing it. I'm very sorry, if my message sounded unfriendly. It wasn't meant to be at all.

Hi, Because dividing class function declaration from definition does make sense, if the interface is to be seen by other modules. If the interface is just for the imlementation namespace of a certain module, I would not even put it into a header. Why? Because I don't want to recompile other modules, if the private interface changes. And because splitting declaration from definition means more administration of code and higher cost. It's overhead, if I don't want to export the functions it declares to others. This I think is a common concern of software engineering, and does not have to do with loving either one programming language or the other. Look, C++ has been called a multiparadigmatic language by it's founder. It should make us free to implement whatever pattern makes sense to us. Werner

Thank you. I'm not quite certain, whether this is, what I want. What I definitely do not want is to prevent the compiler from inlining. I think it knows best. What I actually want is to switch that implicit "inline" off, which is automatically associated with the function, although you don't see it, and which is a sweettalk to the compiler to inline the function whatever might be best. Werner

Hi, is there a way to switch off implicit inline, that is

class ClassOfImplementationNamespace
{
void itsFunc(int x)
{
// let the compiler alone decide
// whether to inline this code,
// it will know better
}
};

should no more give a compiler hint automatically, to inline this. Something like a #pragma NoImplicitInline? Thank you, Werner

Hi, I have tried to use the Win32 clipboard API to copy text to the clipboard, but ist doesn't show up when I try to paste it to a text editor. There is also no Clipboard Format available in the clipboard when I use EnumClipboardFormats. I've used a tutorial cooking book to write that code. Can you say what's wrong? Thanks. void Clipboard::setTo(string const strData) { string::size_type const sizeData = strData.size() * sizeof(TCHAR); HANDLE hData = ::GlobalAlloc(GMEM_MOVEABLE|GMEM_ZEROINIT, sizeData); if (hData) { LPTSTR tszData = static_cast( ::GlobalLock(hData) ); memcpy(tszData, strData.c_str(), sizeData); ::GlobalUnlock(hData); ::OpenClipboard(NULL); ::EmptyClipboard(); ::SetClipboardData(CF_TEXT, hData); } UINT uiFmt = 0; do { uiFmt = ::EnumClipboardFormats(uiFmt); } while (0 != uiFmt); ::CloseClipboard(); } Werner

Hi, I made a COM-client in C++ which uses the import directive and _COM_SMARTPTR_TYPEDEF(Iclogmanager, __uuidof(Iclogmanager)); to access the methods of the COM-Server via a smart pointer. Iclogmanager is a dispinterface and the COM-Object which implements it is a Visual-Fox-Pro COM-Server. Its image is in an exe-file and it runs as a separate process on an other machine. I was surprised to see, that the client crashed, after I released a new version of the server, although I did not even add additional methods. It was just a line of additional code I added within a method. To be exact, it crashed at HRESULT _hr = raw_doQuery(tcFilterMethode, toCollParameters, &_result); After recompilation it worked fine again. This is absolutely not consistent with my idea of COM. Any idea? Thanks an best regards Werner