FSUIPC startup behaviour

[vdkeybus]

Hi Pete,

I've made a C++ wrapper class (fsuipc_wpd) for the FSUIPC client, which takes care of proper error processing. The class is based on the SDK code for Borland, which I also moved in a class (fsuipc).

The result is that I'm using the existing FSUIPC_open() (now: fs->open()) which contains the following part:

	if (!SendMessageTimeout( // send the request
			m_hWnd,       // FS6 window handle
			m_msg,        // our registered message id
			m_atom,       // wParam: name of file-mapping object
			0,            // lParam: offset of request into file-mapping obj
			SMTO_BLOCK,   // halt this thread until we get a response
			2000,	      // time out interval
			&dwError)) {  // return value
		*pdwResult = GetLastError() == 0 ? FSUIPC_ERR_TIMEOUT : FSUIPC_ERR_SENDMSG;
		return false;
	}

	if (dwError != FS6IPC_MESSAGE_SUCCESS) {
		*pdwResult = FSUIPC_ERR_DATA; // FSUIPC didn't like something in the data!
		return false;
	}

I removed the retrying mechanism that was originally there, because SendMessageTimeout() already waits for a FSUIPC response to the message.

However, while I'm trying (one time per second) to make the FSUIPC link, and FS2004 is fired up, I'm getting a successful SendMessage() call (it returns TRUE), but dwError is equal to FSUIPC_ERR_DATA. However, no data was ever sent to FSUIPC.

Is this a possible scenario or should I investigate further for a bug in my software ?

Thanks for the assistance,

J.

[Pete Dowson]

I removed the retrying mechanism that was originally there, because SendMessageTimeout() already waits for a FSUIPC response to the message.

In normal circumstances, SendMessage should be able to deliver its message within that time, yes, but not if FS as a process is tied up doing something which stops it processing messages. This can happen on large or slow disk accesses, such as when FS is building its scenery indices and so on.

I'm getting a successful SendMessage() call (it returns TRUE), but dwError is equal to FSUIPC_ERR_DATA. However, no data was ever sent to FSUIPC.

What do you mean "no data was ever sent"? The SendMessageTimeOut details don't relate to date you've prepared? You've prepared no data? I don't understand what you mean by that.

If FSUIPC receives read and write requests in the data which is shared via the SendMessageTimeout parameters (for that is what they are for, to convey details of memory-mapped file data), then it has certainly "received" data.

If FSUIPC finds anything wrong in the data it is asked to process it returns "FS6IPC_MESSAGE_FAILURE" -- it might actually process some good data then find something bad, in which case you'd get this return. Generaly it would mean an unrecognised request -- for instance, a missing zero terminator on the data would do this.

You'd also get such a return if the access FSUIPC had to make in order to obey the data caused an access violation or any other serious would-be crash in FS -- FSUIPC traps these and logs them. Check the FSUIPC Log file.

You don't get a failure return if FSUIPC simply doesn't read or write some of your data because that part of FS isn't yet ready. In that case Reads normally return zero, and Writes are discarded.

Is this a possible scenario or should I investigate further for a bug in my software ?

It sounds like a bug in the data being provided. I think the above scenarios are the only cases of a Failure return code from the SendMessageTimeout, if it doesn't timeout or fail to get sent for any reason.

If you are multi-threading then check that you are not changing the data in the memory mapped file area before it has been fully dealt with.

Regards,

Pete