Please delve into #connectTo:port: - you will find a timeout there.
________________________________________ From: [email protected] [[email protected]] On Behalf Of Levente Uzonyi [[email protected]] Sent: Thursday, September 23, 2010 7:04 PM To: [email protected] Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote: > Levente, > > I never said that. I said that if it were built properly and used naively, > it would have led to problems. Enter timeouts that should not be present. > The server side is almost impossible to defend as it stands. Oh really? Here is a simple example of a "timeout-free" server and a simple client that you can try in a workspace: "Start a new echo server on 127.0.0.1:12345" [ [ serverSocket := Socket new. serverSocket listenOn: 12345 backlogSize: 10 interface: #[127 0 0 1]. [ serverSocket statusString = 'waitingForConnection' ] whileTrue: [ serverSocket semaphore wait. serverSocket statusString = 'connected' ifTrue: [ | socket | socket := serverSocket accept. [ [ | data | data := socket receiveData. socket sendData: data. socket close ] ensure: [ socket destroy ] ] fork ] ]. serverSocket close ] ensure: [ serverSocket destroy ] ] fork. "Fire up a client which tests the above server and writes it's output to the Transcript." Transcript open. [ clientSocket := Socket new. clientSocket connectTo: #[127 0 0 1] port: 12345. clientSocket sendData: 'Hello Wolrd!'. Transcript show: clientSocket receiveData; cr. clientSocket close ] ensure: [ clientSocket destroy ]. "Stop the server" serverSocket close. If you know how to use Sockets, then it's really easy to do what you want. > > Sockets don't decide when to free resources. Threads and users do. That's right, user timeouts are optional as I showed you in various examples. Levente > > Bill > > > > > ________________________________________ > From: [email protected] > [[email protected]] On Behalf Of Levente Uzonyi > [[email protected]] > Sent: Thursday, September 23, 2010 12:25 PM > To: [email protected] > Subject: Re: [Pharo-project] we need to find a way to declare that an action > is UIless > > On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote: > >> Levente, >> >> We can twist words indefinitely. I have been describing a blocking connect, >> because that is precisely what one should be trying to do: put one thread on >> hold until the calling thread is connected. There is no sensible default >> waiting period for that to happen, and so the framework should not be asking >> for a time limit at all, let alone insisting on one. > > My example was just a proof against the "we need a new socket > implementation because the current one blocks the image" theory. > > And you're wrong about the timeouts. If sockets could wait indefinitely, > the chance for resource leakage would be very high. I'm pretty sure that > even if you omit the timeout (which is possible with the current API) > there will be another timeout at the OS level which you can't/shouldn't > work around. > > Here is an example for a blocking connection without a timeout: > > Transcript open. > [ > | s | > [ > s := Socket new. > s connectNonBlockingTo: #[172 16 0 1] port: 12345. > Transcript show: 'Connecting...'; cr. > [ s statusString = 'waitingForConnection' ] whileTrue: [ > s semaphore wait. "No timeout." ]. > Transcript show: s statusString; cr. > s close ] ensure: [ s destroy ] ] fork. > >> >> ConnectionQueue being at the heart of a Squeak socket server is not my idea; >> I read that in various places, tried, and was appalled to discover that it >> times out, returns nil, etc. It is a complete mess that polls for a time >> period when it should be blocking a thread until an event occurs. > > ConnectionQueue is just a high level API, you can always use _Sockets_. > > > Levente > >> >> Bill >> >> ________________________________________ >> From: [email protected] >> [[email protected]] On Behalf Of Levente Uzonyi >> [[email protected]] >> Sent: Wednesday, September 22, 2010 11:51 PM >> To: [email protected] >> Subject: Re: [Pharo-project] we need to find a way to declare that an action >> is UIless >> >> On Wed, 22 Sep 2010, Schwab,Wilhelm K wrote: >> >>> Levente, >>> >>> Something has to block while a connection attempt is pending, and not just >>> until some arbitrary time limit. The client code is bad enough; the >>> servers are horrible. >> >> If the UI Process is using the Socket and it's using a blocking connection >> method, then - no surprise - it will be blocked. This won't affect other >> processes. >> >> If you were right, the following would block the UI Process for 100 >> seconds, but it doesn't block it at all, just try it: >> >> Transcript open. >> [ 10 timesRepeat: [ >> | s | >> [ >> s := Socket new. >> s connectNonBlockingTo: #[172 16 0 1] port: 12345. >> s >> waitForConnectionFor: 10 >> ifTimedOut: [ Transcript show: 'Couldn''t connect.'; >> cr ]. >> s isConnected ifTrue: [ >> Transcript show: 'Connected.'; cr. ]. >> s close ] ensure: [ >> s ifNotNil: [ s destroy ] ] ] ] fork. >> >> >> What do you mean by "servers"? ConnectionQueue? >> >> >> Levente >> >>> >>> Bill >>> >>> >>> ________________________________________ >>> From: [email protected] >>> [[email protected]] On Behalf Of Levente Uzonyi >>> [[email protected]] >>> Sent: Wednesday, September 22, 2010 9:55 PM >>> To: [email protected] >>> Subject: Re: [Pharo-project] we need to find a way to declare that an >>> action is UIless >>> >>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>> >>>> the one running the gui >>> >>> In that case, you're wrong. The UI Process will be able to run, because >>> other processes using Sockets will wait on Semaphores and not because of >>> "time limits". So I just convinced myself (and hopefully you too) about >>> that using Socket instances will not hang the entire image, just the >>> Process that uses the Socket. Therefore the SocketPlugin is as good as >>> possible. >>> >>> >>> Levente >>> >>>> >>>> >>>> >>>> >>>> ________________________________________ >>>> From: [email protected] >>>> [[email protected]] On Behalf Of Levente Uzonyi >>>> [[email protected]] >>>> Sent: Monday, September 20, 2010 10:14 PM >>>> To: [email protected] >>>> Subject: Re: [Pharo-project] we need to find a way to declare that an >>>> action is UIless >>>> >>>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>>> >>>>> Scratch around, and you will find that the time limits are there to allow >>>>> calls to made on the main thread. >>>> >>>> Where? In the Socket class? And what's the "main thread"? >>>> >>>> >>>> Levente >>>> >>>>> >>>>> >>>>> >>>>> ________________________________________ >>>>> From: [email protected] >>>>> [[email protected]] On Behalf Of Levente Uzonyi >>>>> [[email protected]] >>>>> Sent: Monday, September 20, 2010 8:13 PM >>>>> To: [email protected] >>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an >>>>> action is UIless >>>>> >>>>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>>>> >>>>>> Levente, >>>>>> >>>>>> If they worked correctly, they would, at least under naive client >>>>>> conditions - a connection attempt should try until it is told >>>>>> (#terminate) to stop. Severs that listen for a limited time are broken >>>>>> by design. ConnectionQueue polls as a result - it's pretty bad. >>>>> >>>>> I guess you're using Socket>>#connectTo:port: which uses >>>>> Socket class>>#standardTimeout as timeout (45 seconds). If you don't want >>>>> the default timeout, use #connectTo:port:waitForConnectionFor: or >>>>> implement your own low level method which waits on semaphore until it's >>>>> signaled. If you want to terminate the connection attempt, just signal the >>>>> semaphore yourself, like here: >>>>> >>>>> s := Socket newTCP. >>>>> s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is >>>>> not open." >>>>> [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process >>>>> will stop the connection attempt." >>>>> s semaphore waitTimeoutMSecs: 1000. >>>>> s statusString. "This will simply print the socket status. You can >>>>> terminate the process here if the socket is connected, etc." >>>>> >>>>> And for ConnectionQueue, simply don't use it if you don't like it. It >>>>> doesn't have to poll at all, AFAIK it's just implemented that way. >>>>> Since Sockets use Semaphores which are signaled by the SocketPlugin, they >>>>> don't block the image at all. But correct me if I'm wrong. >>>>> >>>>> >>>>> Levente >>>>> >>>>>> >>>>>> Bill >>>>>> >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: [email protected] >>>>>> [[email protected]] On Behalf Of Levente >>>>>> Uzonyi [[email protected]] >>>>>> Sent: Monday, September 20, 2010 7:01 PM >>>>>> To: [email protected] >>>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an >>>>>> action is UIless >>>>>> >>>>>> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >>>>>> >>>>>>> Guillermo, >>>>>>> >>>>>>> One has to be careful with assuming that something affects only part of >>>>>>> the image. Much of Squeak's networking trouble comes from the fact >>>>>>> that it was designed to block the image for a limited time when it >>>>>>> should have been blocking only one Process *indefinitely*. But, the >>>>>>> remedy for working while blocking operations happen in the background >>>>>>> is threading, and most of the image is deliberately not thread safe. >>>>>> >>>>>> When does a Socket block the image? >>>>>> >>>>>> >>>>>> Levente >>>>>> >>>>>>> >>>>>>> Bill >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: [email protected] >>>>>>> [[email protected]] On Behalf Of Guillermo >>>>>>> Polito [[email protected]] >>>>>>> Sent: Sunday, September 19, 2010 10:56 PM >>>>>>> To: [email protected] >>>>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an >>>>>>> action is UIless >>>>>>> >>>>>>> +1 to Bill's. If we can't have a feedback from the system while doing >>>>>>> silent actions, we can think it just freezed :S. >>>>>>> >>>>>>> And it's something already dicussed, but I don't like actions that >>>>>>> affect only a part of the system blocking my whole image. >>>>>>> >>>>>>> Guille >>>>>>> >>>>>>> On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko >>>>>>> <[email protected]<mailto:[email protected]>> wrote: >>>>>>> On 20 September 2010 03:09, Schwab,Wilhelm K >>>>>>> <[email protected]<mailto:[email protected]>> wrote: >>>>>>>> Slow access can be a big problem. Any such change should be made >>>>>>>> based on measurements so we know what benefit we get at what cost. >>>>>>>> >>>>>>> Yeah, it would be much easier to deal that line in Self or JavaScript, >>>>>>> where you can add any properties to object >>>>>>> on the fly, without need of adding a methods or declaring additional >>>>>>> instance variable in class... >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ________________________________________ >>>>>>>> From: >>>>>>>> [email protected]<mailto:[email protected]> >>>>>>>> >>>>>>>> [[email protected]<mailto:[email protected]>] >>>>>>>> On Behalf Of Igor Stasenko >>>>>>>> [[email protected]<mailto:[email protected]>] >>>>>>>> Sent: Sunday, September 19, 2010 7:56 PM >>>>>>>> To: >>>>>>>> [email protected]<mailto:[email protected]> >>>>>>>> Subject: Re: [Pharo-project] we need to find a way to declare that an >>>>>>>> action is UIless >>>>>>>> >>>>>>>> On 19 September 2010 13:12, Stéphane Ducasse >>>>>>>> <[email protected]<mailto:[email protected]>> wrote: >>>>>>>>> hi guys >>>>>>>>> >>>>>>>>> I tried to add borderStyle to BorderedMorph and the progressbar >>>>>>>>> showing the progress blow up. >>>>>>>>> So we should really have a way to specify silent ui action. >>>>>>>>> Does anybody have an idea how I could do that? >>>>>>>>> >>>>>>>>> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be >>>>>>>>> cool. >>>>>>>>> >>>>>>>> >>>>>>>> use morph propertyAt: #borderStyle >>>>>>>> so you don't have to break your head with it :) >>>>>>>> >>>>>>>> BorderedMorph having an enormous number of subclasses, while some of >>>>>>>> them even don't using any >>>>>>>> kind of borders. That's makes me wonder if anything like color, border >>>>>>>> style etc should belong to root classes >>>>>>>> in hierarchy, like Morph or BorderedMorph. I think that dynamic set of >>>>>>>> properties (which is currently sits in morphic >>>>>>>> extensions are more appropriate storage for them). The only problem is >>>>>>>> that accessing them is much slower than ivars. >>>>>>>> >>>>>>>>> Stef >>>>>>>>> _______________________________________________ >>>>>>>>> Pharo-project mailing list >>>>>>>>> [email protected]<mailto:[email protected]> >>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Igor Stasenko AKA sig. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> [email protected]<mailto:[email protected]> >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> [email protected]<mailto:[email protected]> >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Igor Stasenko AKA sig. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> [email protected]<mailto:[email protected]> >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> [email protected] >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> [email protected] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [email protected] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
