Never done somthing like that, I guess you have to ensure that data is processed in the right order with such a design, as with Windows IOCP sockets as well.
No problem here, I have a worker thread system, the data will always be processed in right order
Yes, I understand, but there's a reason for doing this since it ensures that OnSessionClosed does not fire until winsock buffer is empty.
I see the point, but that would not have to be something that the user application should handle? Why does your library has to ensure that? What would harm if you call OnDataAvailable from FD_CLOSE using the current socket options (in my canse including wsoNoReceiveLoop)? I believe that the one that is using ICS should handle that, because ICS is doing its part, it is calling OnDataAvailable anyway, than, it is up to the user to read or not to read the socket
That may be a workaround in your special case if it doesn't matter to lose same packets, however that isn't a general solution. We have the same problem with SSL, where received encrypted data has to be decrypted first before SessionClosed may be triggered, the workaround is a derived component that overides Do_FD_Close.
I know, but if you still call OnDataAvailable with current socket options, for the ones that has not set wsoNoReceiveLoop (By default) the behaviour will still be the same right... for the ones that has set wsoNoReceiveLoop (like me) OnDataAvailable will still be called, and if I can afford to lose the packets I just don´t process the data, this will depend on the ones that are designing an application using ICS. In my workaround I´m still calling OnDataAvailable, that wasn´t change, but it is called with wsoNoReceiveLoop, so, it is up to my application to handle or not to handle the data, if my application does not handle it, it will lose packets (which in some cases are ok)
Eric
-- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
