Hi again :) * David Schwartz wrote on Mon, Sep 03, 2007 at 17:36 -0700: > > sorry, seems I'm unable to get it (I read it several times :)). > > 2) The application calls 'write', expecting it to block until > all the data can be written.
yes, we already talked about. I still think that this application is simply wrong (`write writes up to count bytes', so maybe less than count, for example zero or one). I remember that you considered a related assumption as strange :) > > If data was put to the read buffer (whether > > verified or not), select and read won't block. If data is in the > > buffer and by contract can be only removed by read (or close > > maybe, doesn't matter), read won't block. > > Wouldn't this work? I mean, at least theoretically? > > No, because 'select' has to work on protocols with all > different kinds of semantics. It is not theoretically possible > to ensure that these semantics will make sense with every > protocol 'select' might be used with. oki, maybe this is how it is implemented. But if ANY communication would be implemented using some `kernel I/O buffer', select could work. A price for this could be to lose some functionality, such as retroactive CRC check frame dropping (for whomever this would make sense). > > > Consider the following: > > > > > > 1) An application disables UDP cheksums. > > > > > > 2) An application calls 'select' and gets a 'read' hit on a > > > packet with a bad checksum. > > > So this would mean the bad checksum would not be > > detected/evaluated and the data would be stored to the > > buffer, right? > > Not likely. That would mean the kernel has to verify the > checksum in a separate operation, which is a waste of memory > bandwidth. Is is a big difference whether to calculate the CRC during select instead of inside read? > > > 3) An application peforms a socket option call asking for > > > checksum checking to be enabled. > > > ok, so from now new arriving data would not stored anymore to > > the input buffer unless checksum was proven (not applied > > retroactive of course - wouldn't be possible, because the > > checksums where not even stored). > > Suppose the input buffer *is* the packet buffer. Such an implementation would be wrong, because it could never give the read won't block-guarantee :-) > > > 4) An application calls 'recvmsg'. > > > > > > Should it get the packet with the bad checksum? In other > > > words, are you really sure you want 'select' to *change* > > > the semantics of the socket? > > > It gets the data arrived in the packet where the checksum was > > not evaluated at all, because this was configured, yes, that > > would be what I expect. select should not influence the > > mechanism at all (checksum verification). > > But you are demanding that 'select' influence the mechanism, > because you are saying that because there was a 'select' hit, > the packet must be returned, even if a subsequent change asks > for it to be discarded. This subsequent change IMHO does not have to be able to discard already received packet (it affect the packets to be retrieved from this time on). This was what I meant with this option does not need to be retroactive (`with retrospective effect`?). > If not for the 'select' hit, it would be perfectly reasonable > to discard the packet later. But not required, so why wasting the additional resources? The framing and headers (at least the CRC) would need to be stored (instead of just the payload data). > > yes, of course, the device may not even know about accept at > > all. But I mean, for read non-blocking is guaranteed > > according to some understandings but for accept noone claims > > this (but expects it because the working examples show it > > :)). > > This is the problem. At one time, people expected it for > 'accept', and their code broke. Why tell people to repeat that > mistake? ohh, no, this was not what I meant at all! Of couse I completely agree to tell people to use non-blocking I/O when wanting non-blocking I/O! As it is not required to rely on the guarantee that some read after select would not block, so they should not rely on it (this works if this guarantee does not exist logically, or if the guarantee is not implemented correctly or not for all types or whatever - works in all cases so it is the safe way). I also understood (and agree) to your summary `select does not guarantee that read will not block'. (it is just the reason for it or `theoretical' vs. `practical'. I think, it could `theoretical' be made this way, actually, I assume [:)] it even `practical' sometimes/often the case). > Consider a 'select' followed by a 'read' in another thread. Is > that the operation that shouldn't block or are the 'select' and > the 'read' unrelated? If the read was started (called) after the select finished (returned), then this read (and only this read) is the subsequent operation. If two threads invoke reads concurrently, there is no way for the threads to determine which read will block and which will not block, so the program should not do so. > > for read, it would return ready for read as soon as some data > > arrived in some local buffer I assume? Of course this requires > > the usage of such intermediate buffers (which is not required by > > the read API which is unlimited, so a performant implementation > > would do things differently). > > Data won't arrive until you call 'read'. And 'read' is blocking > on NFS files normally. You'd need a non-blocking read, followed > by 'select', followed perhaps by repeating the 'read'. Wouldn't this mean, that select would not work as specified and thus would be a bug? Maybe I'll play with select on a NFS file when I'd get some time. Could become surprising after that what I learned now... :) > You might be able to define a narrow subset of cases for which > the guarantee could be made, but then you'd just be repeating > the mistakes of the past. People did this same thing with > 'accept', and it bit them on the butt. > > Again, we can learn from mistakes or we can repeat them. If you > want non-blocking behavior, just ask for it. Then you are > assured to get it. Yes, this is the straight-forward, reliable, simple to understand and pragmatic way, as you already told, right. This one I understood. When the fd will never block, openssl also will never block, so this simply is the easy and safe way of working. Thanks for your explanation. Hope my questions weren't too annoying for the list. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
