On Thu, Sep 23, 2010 at 10:01 AM, Schwab,Wilhelm K <[email protected]>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. > > Sockets don't decide when to free resources. Threads and users do. > Wilhelm, asking a socket to timeout after a while is /not/ a socket "deciding when to free resources". The socket doesn't decide for itself. The client of the socket, be that a server or a user or whatever, does. > > 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
