On Thu, 23 Sep 2010, Schwab,Wilhelm K wrote:
Please delve into #connectTo:port: - you will find a timeout there.
As I said, only the server is timeout free. If you want a timeout-free
example for a client, you can find one in this thread.
Levente
________________________________________
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
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
