Ahh, I see :) Doru On 26 Oct 2010, at 22:14, Lukas Renggli wrote:
No, I fixed it in Kom.
Lukas
On 26 October 2010 22:12, Tudor Girba <tudor.girba@gmail.com> wrote:
So, you always have to pass a script that restarts the server? This sounds like a workaround, right?
Cheers, Doru
On 26 Oct 2010, at 21:48, Lukas Renggli wrote:
Ok, I think I solved the issue. Restarting the server on startup seems to solve the problem on all my machines.
Thanks again for the hints!
Lukas
On 26 October 2010 20:41, Lukas Renggli <renggli@gmail.com> wrote:
Thank you Eliot for the answer. I will have to investigate and see if this is a Seaside specific issue or related to Kom.
Lukas
2010/10/26 Eliot Miranda <eliot.miranda@gmail.com>:
---------- Forwarded message ---------- From: Eliot Miranda <eliot.miranda@gmail.com> Date: Tue, Oct 26, 2010 at 10:23 AM Subject: Re: Cog VM doesn't start to listen on socket To: Lukas Renggli <renggli@gmail.com>
Hi Lukas, obviously we use sockets intensively in Teleplace and we see no problems that are to do with Cog. But Cog does throw up timing issues in your code because it has very different performance to the base VM (Smalltalk code is faster, most primitives have the same speed, allocation is slightly faster, etc). So my gut feeling is that what you're seeing is a timing related issue (race condition?) that is revealed when on Cog and hidden when on the normal VM. HTH (yeah, right... ed.) Eliot
On Tue, Oct 26, 2010 at 5:04 AM, Lukas Renggli <renggli@gmail.com> wrote:
Hi Eliot,
I noticed that on the Cog VM the Kom Seaside server does not automatically start to listen, even if there is a process waiting at the semaphore of the socket. Singaling that semaphore from the process browser fixes the problem and the Cog image is fully working until the next time it is opened.
The exact same image opened with an old VM does not show the problem and immediately starts to listen by itself.
Did anybody else notice the same problem? Anybody found a solution?
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."