2010/1/3 Benoît Minisini <gam...@users.sourceforge.net>: > <Kadaicha irony mode> > > I'm not sure that the MSDN documentation is a good reference for socket > programming: > > - The Microsoft documentation is often not connected to the reality it tries > to describe. > > - The Windows socket implementation often behaves differently than the other > OS implementation.
I wasn't suggesting it was. You took the information completely out of context. The correct context is "As you can see, the idea of a timeout is not a strange one to many languages on either Unix, Linux or Windows." i also included Linux and perl information. > My problem is: how can I have the easier Socket interface in Gambas for all > possible socket scenarii? > > That is the reason why I said that if the user asks for writing a big chunk of > data to the socket, I should temporarily other blocking mode. Maybe he is > doing something wrong (i.e. using a non-blocking socket, but not the Write > event), but Gambas can't be sure. Gambas should mind its own business and do as it's told. If the program hangs or SIG faults then bad luck. Your argument here appears to be the same as Doriano's; the programming language should know what is happening, not the program. You are making program implementation decisions at the language level. Anyway, that's how it comes across when I read it, even if that's not what is meant. I think you're on the wrong track. You do not need to turn on blocking temporarily in gambas for large chunks of data at all; You can keep the gambas socket in full asynch mode if the maximum size of the transmit buffer is specified by gambas, can be made smaller by the programmer, and an event is implemented to allow the socket to request more data from the application, plus a timeout event to manage excessive idle time during a transmit/receive operation. The timeout should operate in both synch and asynch mode, whereas the data request event should only be triggered in asynch mode. In that way, the programmer has a very powerful tool in being able to use both blocking and non-blocking at will to perform highly complex and relatively simple functions. Blocking sockets is a problem for gambas because it is single-threaded and can cause the application to be unresponsive when large chunks of data are sent between systems on a slow connection. However by knowing the buffer size and having a "more data needed" event, the programmer can keep the socket in asynch mode. > Gambas 2 behave this way (not my decision), and I removed this behaviour in > Gambas 3, but now I don't remember why. I should test all the scenarii... There is no need to remember why it was turned off in gb3. It makes sense to turn it off if you want an asynch socket, however turning it off in gb3 without implementing a known buffer size and a request for additional data without a timeout has broken it. Well, that's my opinion. ------------------------------------------------------------------------------ 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 Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
