Kadaitcha Man ha scritto: > 2010/1/5 Doriano Blengino <[email protected]>: > > I disagree. Blocking mode guarantees known certainties, as defined by > any number of RFC documents. > Pardon me... I think that RFCs have nothing to do with blocking mode, unless you find an RFC which says "an operating system SHOULD use blocking sockets, but it MAY also use non-blocking ones". As I did not read all the RFCs around, may be you are right; in that case, I apologize. > >> - if you want to send 700Mb in a single instruction, well, you can do >> it. But you can not send 700Mb *and* want to be non-blocked! Look at this: >> >> write #1, my_700_mb_block >> if error then... >> > > As I said, I would not, even with today's technology, ever send more > than 512Kb. > > >> In blocking mode all is fine: >> > > Not if the connection can't handle it. > > No disrespect here but you youngsters simply do not seem to understand > the value of testing and proving. You seem to be interested only in > how reasonable your own thoughts seem to yourselves. Hell, if it makes > sense to you, it must be right, right? > Do you know how old I am? May be. I don't look at myself as a youngster, but you are entitled to do so, especially if you are retired. But I remember to you that I did write a TCP/IP stack from scratch. Probably this is not enough for you, but as you can imagine, I had a lot of work to do, and tries and tries and tries. And just because of this, I can say that tries are not enough - instead, they are very dangerous if not supported by a deep knowledge. But our opinions can diverge a lot at this point. > >> the first instruction takes several >> minutes, and then terminates either with error or by having completed >> the job. The second instruction takes the appropriate actions. But if >> the first statement is non-blocking, the second instruction can not test >> for success or not - you should test at later time, perhaps several >> hours later. So non-blocking mode raises event to notify about what >> happened in background. >> > > Gibberish. Sorry. Je ne comprends pas. > > >> Things are getting complicated... >> > > Only because you are complicating them. > > If I write a program to "wait until the cows come home" then wait > until the cows come home the program should do, without you or the > programming language deciding otherwise. > > Do you understand that? > > Really, no insult intended, but I sincerely doubt that you do > understand. You seem to interpret "general purpose programming > language" to mean what you and you alone consider to be reasonable. > You have lost contact with the idea that a program must do exactly as > it is told and nothing more. Instead you insert the idea, "What if the > programmer does something they didn't mean to do? Merde! How do I deal > with that?" > > And so you end up in the never-ending circles you are currently caught in. > Ok, I am speaking about things too philosophic, loosing contact with reality. There is no point in spending time in such things. But I can assure you that I am not stuck in anything - simply we don't understand each other, probably because english is not my language.
And now, let's stop this nowhere-going discussion. We presented our ideas, so we know what the other thinks, and this is already a good thing. May be that someone reading us can take advantage, may be not. Best wishes for your proxy, and let me know if something new happens in your software. Regards, Doriano ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Gambas-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gambas-user
