CAsyncSocket message handling
in [MFC]
|
From: Stephen Myers on 23 Sep 2009 11:59 neilsolent wrote: >> Does calling the socket's Close() method satisfy your on demand requirement? >> >> Steve > > Yes, Close() is the call - but the issue for me is knowing when you > can call it! > I don't believe you can call Close() whenever you like - as there > might be queued up notification messages (OnReceive() callbacks etc) > which will point at a bad handle once Close() has been called, and > hence lead to a crash like the one above. We have got into this > message-pump debate, but I think it is beside the point. It is not > clear how the MFC-style application and built-in message pump does > anything to get around this - you still can't close the socket on > demand (only when a Windows message tells you to). > Unless someone knows different .. I won't say that I know, but that is exactly what I'd use. You may get notifications after the Close call, but that's OK. I would expect that OnClose() would be queued like any other socket message, and it would be reasonable to delete the socket at that point. Any messages received between your Close() call and OnClose() would have to be handled. This should be straight forward as you decided to call Close in the 1st place. Steve
From: Joseph M. Newcomer on 23 Sep 2009 23:06 As far as I can tell, that is correct. There can be any number of messages received after the Close call, representing packets that were already in flight. The FD_CLOSE/OnClose notification will be queued up behind all those. It otherwise appears that after the OnClose that the object will never receive another message. The error that was originally reported appears to be the result of deleting the object before the last message (the FD_CLOSE notification) had been processed. joe On Wed, 23 Sep 2009 10:59:58 -0500, Stephen Myers <""StephenMyers\"@discussions(a)microsoft.com"> wrote: >neilsolent wrote: >>> Does calling the socket's Close() method satisfy your on demand requirement? >>> >>> Steve >> >> Yes, Close() is the call - but the issue for me is knowing when you >> can call it! >> I don't believe you can call Close() whenever you like - as there >> might be queued up notification messages (OnReceive() callbacks etc) >> which will point at a bad handle once Close() has been called, and >> hence lead to a crash like the one above. We have got into this >> message-pump debate, but I think it is beside the point. It is not >> clear how the MFC-style application and built-in message pump does >> anything to get around this - you still can't close the socket on >> demand (only when a Windows message tells you to). >> Unless someone knows different .. > >I won't say that I know, but that is exactly what I'd use. You may get >notifications after the Close call, but that's OK. I would expect that >OnClose() would be queued like any other socket message, and it would be >reasonable to delete the socket at that point. Any messages received >between your Close() call and OnClose() would have to be handled. This >should be straight forward as you decided to call Close in the 1st place. > >Steve Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: neilsolent on 27 Sep 2009 06:04 On 24 Sep, 04:06, Joseph M. Newcomer <newco...(a)flounder.com> wrote: > As far as I can tell, that is correct. There can be any number of messages received after > the Close call, representing packets that were already in flight. The FD_CLOSE/OnClose > notification will be queued up behind all those. It otherwise appears that after the > OnClose that the object will never receive another message. The error that was originally > reported appears to be the result of deleting the object before the last message (the > FD_CLOSE notification) had been processed. > joe I wasn't 100% convinced that Windows would reliably send the OnClose() notification, especially if I initiated the shutdown of the socket (I thought you might only get the OnClose() when the peer initiated the shutdown by closing it's end of the socket). Hence I went for calling AsyncSelect(0) to stop any more messages of any kind coming in, then posting my own message to the queue to request deletion (knowing this message is gauranteed to come after any Windows notifications). I suspect either way works. Back on the topic of the message pump.. This project was originally built in VC++ starting with the options "Win32 Console Application" -> "An application that supports MFC" - and the program It runs as a service. Was there a step I was supposed to do to get the standard MFC message pump? I wasn't really trying to go non-standard - just doing what I needed to do to make it work !
From: Joseph M. Newcomer on 27 Sep 2009 12:14
In this case, you would create a UI thread, not a worker thread, and the message pump comes free. joe On Sun, 27 Sep 2009 03:04:56 -0700 (PDT), neilsolent <n(a)solenttechnology.co.uk> wrote: >On 24 Sep, 04:06, Joseph M. Newcomer <newco...(a)flounder.com> wrote: >> As far as I can tell, that is correct. �There can be any number of messages received after >> the Close call, representing packets that were already in flight. �The FD_CLOSE/OnClose >> notification will be queued up behind all those. �It otherwise appears that after the >> OnClose that the object will never receive another message. �The error that was originally >> reported appears to be the result of deleting the object before the last message (the >> FD_CLOSE notification) had been processed. >> � � � � � � � � � � � � � � � � joe > >I wasn't 100% convinced that Windows would reliably send the OnClose() >notification, especially if I initiated the shutdown of the socket (I >thought you might only get the OnClose() when the peer initiated the >shutdown by closing it's end of the socket). Hence I went for calling >AsyncSelect(0) to stop any more messages of any kind coming in, then >posting my own message to the queue to request deletion (knowing this >message is gauranteed to come after any Windows notifications). I >suspect either way works. > >Back on the topic of the message pump.. This project was originally >built in VC++ starting with the options "Win32 Console Application" -> >"An application that supports MFC" - >and the program It runs as a service. Was there a step I was supposed >to do to get the standard MFC message pump? I wasn't really trying to >go non-standard - just doing what I needed to do to make it work ! Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |