> > So, do you confirm that unblock handler can't be reliably implemented if 
> there is more than one thread in RM?
> 
> No.  It should be able to architect your manager to handle
> this issue.  A rcvid in a manager maps to a particular
> thread in a client.  Said thread sends a message on a fd
> which maps to an ocb in the server so the rcvid also
> eventually maps to an ocb in the server.  When the server's
> unblock callout is called it can check if it's servicing the
> rcvid in question on the passed ocb and if an unblock is
> actually pending.

Since pulse is delivered asynchronously, even if you find that the ocb is servicing the recvid with matching value you 
don't know if it's still your recvid or it is the next recvid with matching value assigned to it by coincidence.
As for checking MsgInfo... First, it looks to me that MsgInfo is somehow "thread-oriented" and should only be called 
from the thread that had actually received that recvid. At least it stops returning the info as soon as the thread 
returns to dispatch_block() even though the recvid itself has not been replied yet. That's why, if handler thread did 
not save its struct _msg_info itself, you won't be able to access it later from unblock handler. And even if it saves 
the info, it's of no use for this particular purpose as it might be outdated (saved before the unblock pulse receipt and
 thust, not having the flag set).

> If not it's either replied already or the
> unblock callout arrived before the message callout.  Both
> cases should be able to be handled.

Yes, all those cases could be handled if it would be possible to use MsgInfo from unblock callout.

> On Tue, Aug 11, 2009 at 08:24:02AM -0400, Oleh Derevenko wrote:

> > So, do you confirm that unblock handler can't be reliably implemented if 
> there is more than one thread in RM?
> 
> No.  It should be able to architect your manager to handle
> this issue.  A rcvid in a manager maps to a particular
> thread in a client.  Said thread sends a message on a fd
> which maps to an ocb in the server so the rcvid also
> eventually maps to an ocb in the server.  When the server's
> unblock callout is called it can check if it's servicing the
> rcvid in question on the passed ocb and if an unblock is
> actually pending.  If not it's either replied already or the
> unblock callout arrived before the message callout.  Both
> cases should be able to be handled.

OK, I try to check for (info.flags & _NTO_MI_UNBLOCK_REQ) before handling the request to make sure I've not missed an 
unblock callout before the request itself. It's a single-threaded RM (actually, a multithreaded but they all are 
serialized on a single mutex on entries to callouts).

Here is what I get (the logs are stripped from unnecessary info; best viewable with fixed width font)

4  15  09/08/20 19:36:10.082  CResourceManager::InternalRead                      rm.cpp:1119          CResourceManager:
:Read() (ocb=&085cd270, Path="prop/Mouse_Y.txt.cng", rcvid=4390954)
4  15  09/08/20 19:36:10.082  CDRMRequestData::ReadEx                             DataRequest.cpp:179  Blocked in cng 
read
4  15  09/08/20 19:36:10.082  CResourceManager::InternalRead_PreProcessOCB        rm.cpp:1267          Client has been 
blocked (File="prop/Mouse_Y.txt.cng", ocb=&085cd270, Attr=&088f4868, Flow Suspended=false)
...
4  14  09/08/20 19:36:10.660  CResourceManager::InternalUnblock                   rm.cpp:1702          CResourceManager:
:InternalUnblock() (ocb=&085cd270, rcvid=4390954, Path="prop/Mouse_Y.txt.cng")
4  14  09/08/20 19:36:10.660  CResourceManager::UnblockAllActiveConnectionsForOCB rm.cpp:3239          Unblocking active
 connection (Name="read", Index=0)
4  14  09/08/20 19:36:10.660  CResourceManager::DoReplyRead                       rm.cpp:1612          read() unblocked
...
4  14  09/08/20 19:36:10.662  CDRMRequestData::OnBlockEnd                         DataRequest.cpp:319  New data received
 for file (Path="prop/Mouse_Y.txt.cng")
4  14  09/08/20 19:36:10.662  CDRMRequestData::OnBlockEnd                         DataRequest.cpp:340  Client is not 
connected - store changes
...
4  17  09/08/20 19:36:10.662  CResourceManager::InternalCloseOCB                  rm.cpp:1484          CResourceManager:
:CloseOCB() (ocb=&085cd270, Path="prop/Mouse_Y.txt.cng")
4  17  09/08/20 19:36:10.662  -                                                   DataRequest.cpp:302  Unregistering 
property notification
4  17  09/08/20 19:36:10.662  CResourceManager::InternalCloseOCB                  rm.cpp:1508          Closing file 
(Path="prop/Mouse_Y.txt.cng", ocb=&085cd270, Attr=&088f4868)
...
4  18  09/08/20 19:36:11.648  CResourceManager::ProcessRequest_Open               rm.cpp:2166          Open request has 
been aborted immediately due to pending unblock request (Rcvid=4390954, Path="prop/Mouse_Y.txt.cng")

 
Here the file read request was blocked in RM. Then the unblock request has been received for it. The file read has been 
aborted. Then the file has been closed by the client (close() callout does not check for _NTO_MI_UNBLOCK_REQ flag!!!). 
And then, the following open() still detects the _NTO_MI_UNBLOCK_REQ flag set in msg_info and aborts immediately.

So, it's OK the rcvid can be reused. But is _NTO_MI_UNBLOCK_REQ state ever cleared from it?

I check for the flag like this:

int CResourceManager::CheckRequestImmediateAborters(resmgr_context_t *ctp)
{
	int iResult;

	do 
	{
		int rcvid = ctp->rcvid;

		if (rcvid != 0)
		{
			ASSERTE(rcvid != -1);

			struct _msg_info info;

			int iInfoResult =...