- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Socket timeout terminates COG VM

by StÃ©phane Ducasse

I just wanted to know if I was correct else I agree with you ;D On Oct 11, 2011, at 2:29 PM, Igor Stasenko wrote: > On 11 October 2011 09:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi igor >> >> I imagine that if the server is not run headless then the screen will be filled up with debuggers and people can try if they succeed to >> connect to the image using a remote tools. Even if I prefer a real headless mode, is my sentence correct? >> > Yes. But read the phrase "filled up with debuggers" again: i bet that > in 99% cases people just closing debuggers and not wasting time > to analyse the cause of every error by opening individual debugger etc. > It makes no sense. What makes sense is to add code which doing this > automatically + some error logging. > >> Stef >> >> >> On Oct 11, 2011, at 1:05 AM, Igor Stasenko wrote: >> >>> On 11 October 2011 01:27, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>> John, >>>> >>>> No question, the punishment certainly exceeds the crime :) I was making a general plea for what I really believe is the correct way to build network software. >>>> >>> So you prefer leaving an image in some undefined state, potentially >>> leaking system resources, >>> because of unhandled exception which nobody cares to handle? >>> At best what you can have then is, when your critical process will >>> enter an endless error-producing loop >>> is just bogging all system resources or hanging an image, without >>> giving you any idea what's going on. >>> So , if you prefer such kind of punishment for your crimes, just use >>> image prior to 1.3 and be happy :) >>> >>>> Bill >>>> >>>> >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of John Toohey [jt(a)parspro.com] >>>> Sent: Monday, October 10, 2011 5:24 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] Socket timeout terminates COG VM >>>> >>>> The exception is not coming from my code, if it was I could trap it. >>>> Regardless, isn't shutting the VM down a bit of overkill in this case? >>>> >>>> On Mon, Oct 10, 2011 at 17:12, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> On 10 October 2011 23:19, John Toohey <jt(a)parspro.com> wrote: >>>>>> Hi, >>>>>> >>>>>> I've had a problem since 1.0 with socket timeouts throwing exceptions >>>>>> and invoking the debugger in my headless images. I don't know why a >>>>>> socket timeout is considered exceptional, but I've gotten used to >>>>>> using VNC to log into the server and close the debuger windows. >>>>>> However, I've moved to COG and the latest one-click images, and now >>>>>> the error terminates the VM. >>>>>> >>>>>> My app is a standard Seaside server, using the streaming connector for >>>>>> Comet support. >>>>>> >>>>>> I've attached the PharoDebug.log. It would be appreciated if anyone >>>>>> could help me with this problem, as I'm at a loss where to even begin. >>>>>> >>>>> >>>>> So, just put an exception handler, and handle this exception in a >>>>> manner you want >>>>> and then your image will keep working! :) >>>>> >>>>>> >>>>>> Using Pharo1.3 #13298 on Lucid32 (Ubuntu) >>>>>> >>>>>> >>>>>> -- >>>>>> ~JT >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> ~JT >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> > > > > -- > Best regards, > Igor Stasenko. >

Oct. 11, 2011

Re: [Pharo-project] socket.io

by Igor Stasenko

On 11 October 2011 13:59, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > > Philippe Marschall-2 wrote: >> >> On 10/10/2011 09:47 PM, Herby VojÄÃk wrote: >>> Is there / planning a socket.io (server) support in Pharo? I am making >>> suite >>> of client-server application where I strongly consider socket.io as the >>> communication layer; there is no problem with clients, but at the >>> server-side, socket.io seems only to be supported by its native node.js >> >> Without async IO supporting WebSockets does not seem to make much sense. >> >> ... >> >> Cheers >> Philippe >> > > I do not understand the rationale... "async IO" (more correctly, as Ryan > Dahl often points, is "non-blocking IO", there is nothing async in node.js, > it's single-threaded) is just the alternative model to "threaded, blocking > IO". What does it have in common with sense of making WebSockets work? > > Nevertheless, it seems there is no support of server-side socket.io in > Pharo, I conclude. :-( > Sockets in Pharo are not blocking the whole VM. What they block is the process which working with concrete socket. But other processes can still run, while one waiting data / even from single socket. > Thanx, Herby > > -- > View this message in context: http://forum.world.st/socket-io-tp3891592p3893938.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko.

Oct. 11, 2011

Re: [Pharo-project] socket.io

by Philippe Marschall

On 10/11/2011 01:59 PM, Herby VojÄÃk wrote: > > Philippe Marschall-2 wrote: >> >> On 10/10/2011 09:47 PM, Herby VojÄÃk wrote: >>> Is there / planning a socket.io (server) support in Pharo? I am making >>> suite >>> of client-server application where I strongly consider socket.io as the >>> communication layer; there is no problem with clients, but at the >>> server-side, socket.io seems only to be supported by its native node.js >> >> Without async IO supporting WebSockets does not seem to make much sense. >> >> ... >> >> Cheers >> Philippe >> > > I do not understand the rationale... "async IO" (more correctly, as Ryan > Dahl often points, is "non-blocking IO", there is nothing async in node.js, > it's single-threaded) is just the alternative model to "threaded, blocking > IO". What does it have in common with sense of making WebSockets work? Pharo only supports "threaded, blocking IO", so for each WebSocket (or long-polling, or forever i-frame) connection we need to have a Process lingering around. That makes Pharo less than ideal for building a socket.io server. Cheers Philippe

Oct. 11, 2011

[Pharo-project] Leading Banking Services in Luxembourg is seeking

by StÃ©phane Ducasse

Software Developer - SMALLTALK Role/Area : developer to participate to technical design, coding, unit testing and bug fixing in the context of GVAS 2011. Qualifications/required skills : Software engineer with advanced SMALLTALK development skills. Experience in smalltalk development is required. If possible, experience in financial industry and ability to coach people. English is the working language. Starting date : ASAP. Estimated duration of the mission : until June 2012. Location : LUXEMBOURG. Contact: Bertrand Wunderlich <bwunderlich(a)nfs.lu> Stef

Oct. 11, 2011

Re: [Pharo-project] Socket timeout terminates COG VM

by Igor Stasenko

On 11 October 2011 09:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi igor > > I imagine that if the server is not run headless then the screen will be filled up with debuggers and people can try if they succeed to > connect to the image using a remote tools. Even if I prefer a real headless mode, is my sentence correct? > Yes. But read the phrase "filled up with debuggers" again: i bet that in 99% cases people just closing debuggers and not wasting time to analyse the cause of every error by opening individual debugger etc. It makes no sense. What makes sense is to add code which doing this automatically + some error logging. > Stef > > > On Oct 11, 2011, at 1:05 AM, Igor Stasenko wrote: > >> On 11 October 2011 01:27, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>> John, >>> >>> No question, the punishment certainly exceeds the crime :) Â Â I was making a general plea for what I really believe is the correct way to build network software. >>> >> So you prefer leaving an image in some undefined state, potentially >> leaking system resources, >> because of unhandled exception which nobody cares to handle? >> At best what you can have then is, when your critical process will >> enter an endless error-producing loop >> is just bogging all system resources or hanging an image, without >> giving you any idea what's going on. >> So , if you prefer such kind of punishment for your crimes, just use >> image prior to 1.3 and be happy :) >> >>> Bill >>> >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of John Toohey [jt(a)parspro.com] >>> Sent: Monday, October 10, 2011 5:24 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Socket timeout terminates COG VM >>> >>> The exception is not coming from my code, if it was I could trap it. >>> Regardless, isn't shutting the VM down a bit of overkill in this case? >>> >>> On Mon, Oct 10, 2011 at 17:12, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> On 10 October 2011 23:19, John Toohey <jt(a)parspro.com> wrote: >>>>> Hi, >>>>> >>>>> I've had a problem since 1.0 with socket timeouts throwing exceptions >>>>> and invoking the debugger in my headless images. I don't know why a >>>>> socket timeout is considered exceptional, but I've gotten used to >>>>> using VNC to log into the server and close the debuger windows. >>>>> However, I've moved to COG and the latest one-click images, and now >>>>> the error terminates the VM. >>>>> >>>>> My app is a standard Seaside server, using the streaming connector for >>>>> Comet support. >>>>> >>>>> I've attached the PharoDebug.log. It would be appreciated if anyone >>>>> could help me with this problem, as I'm at a loss where to even begin. >>>>> >>>> >>>> So, just put an exception handler, and handle this exception in a >>>> manner you want >>>> and then your image will keep working! :) >>>> >>>>> >>>>> Using Pharo1.3 #13298 on Lucid32 (Ubuntu) >>>>> >>>>> >>>>> -- >>>>> ~JT >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>>> >>> >>> >>> >>> -- >>> ~JT >>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > -- Best regards, Igor Stasenko.

Oct. 11, 2011

Re: [Pharo-project] Socket timeout terminates COG VM

by Henrik Sperre Johansen

On 11.10.2011 14:17, Henrik Sperre Johansen wrote: > On 11.10.2011 01:00, John Toohey wrote: >> Henrik, >> >> Could you explain this in a little more detail for me? Are you saying >> the socket timeout is really a semaphore problem? >> > Yes, in that Sockets block on Semaphores registered in the vm, which > are then signalled from the external plugin. > The number of objects for which this signalling is done does not grow > automatically, see: > http://code.google.com/p/pharo/issues/detail?id=4505 > for the discussion/rationale behind now raising an error when there's > no free space anymore, instead of silently losing signals. > > The methods (with comments) in image resulting from this issue, and > interesting to read in this context is: > VirtualMachine >> #maxExternalSemaphores: > - you can change inProduction to true, and it will no longer crash, > but write you a warning that you might be losing signals due to too > little default space. > ExternalSemaphoreTable >> #collectionBasedOn:withRoomFor: and > #freedSlotsIn:ratherThanIncreaseSizeTo: > - comments should hopefully be useful > > Cheers, > Henry > Reading it over, I see the temporary needToGrow in #freedSlotsIn: ... is misnamed. It should be freedSlots. Cheers, Henry

Oct. 11, 2011

Re: [Pharo-project] Socket timeout terminates COG VM

by Henrik Sperre Johansen

On 11.10.2011 01:00, John Toohey wrote: > Henrik, > > Could you explain this in a little more detail for me? Are you saying > the socket timeout is really a semaphore problem? > Yes, in that Sockets block on Semaphores registered in the vm, which are then signalled from the external plugin. The number of objects for which this signalling is done does not grow automatically, see: http://code.google.com/p/pharo/issues/detail?id=4505 for the discussion/rationale behind now raising an error when there's no free space anymore, instead of silently losing signals. The methods (with comments) in image resulting from this issue, and interesting to read in this context is: VirtualMachine >> #maxExternalSemaphores: - you can change inProduction to true, and it will no longer crash, but write you a warning that you might be losing signals due to too little default space. ExternalSemaphoreTable >> #collectionBasedOn:withRoomFor: and #freedSlotsIn:ratherThanIncreaseSizeTo: - comments should hopefully be useful Cheers, Henry

Oct. 11, 2011

Re: [Pharo-project] socket.io

by StÃ©phane Ducasse

hi herby what is specific with socket server? Stef >> On 10/10/2011 09:47 PM, Herby VojÄÃk wrote: >>> Is there / planning a socket.io (server) support in Pharo? I am making >>> suite >>> of client-server application where I strongly consider socket.io as the >>> communication layer; there is no problem with clients, but at the >>> server-side, socket.io seems only to be supported by its native node.js >> >> Without async IO supporting WebSockets does not seem to make much sense. >> >> ... >> >> Cheers >> Philippe >> > > I do not understand the rationale... "async IO" (more correctly, as Ryan > Dahl often points, is "non-blocking IO", there is nothing async in node.js, > it's single-threaded) is just the alternative model to "threaded, blocking > IO". What does it have in common with sense of making WebSockets work? > > Nevertheless, it seems there is no support of server-side socket.io in > Pharo, I conclude. :-( > > Thanx, Herby > > -- > View this message in context: http://forum.world.st/socket-io-tp3891592p3893938.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Oct. 11, 2011

Re: [Pharo-project] socket.io

by Herby VojÄÃk

Philippe Marschall-2 wrote: > > On 10/10/2011 09:47 PM, Herby VojÄÃk wrote: >> Is there / planning a socket.io (server) support in Pharo? I am making >> suite >> of client-server application where I strongly consider socket.io as the >> communication layer; there is no problem with clients, but at the >> server-side, socket.io seems only to be supported by its native node.js > > Without async IO supporting WebSockets does not seem to make much sense. > > ... > > Cheers > Philippe > I do not understand the rationale... "async IO" (more correctly, as Ryan Dahl often points, is "non-blocking IO", there is nothing async in node.js, it's single-threaded) is just the alternative model to "threaded, blocking IO". What does it have in common with sense of making WebSockets work? Nevertheless, it seems there is no support of server-side socket.io in Pharo, I conclude. :-( Thanx, Herby -- View this message in context: http://forum.world.st/socket-io-tp3891592p3893938.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 11, 2011

[Pharo-project] Looking for Gjallar

by Edgar J. De Cleene

Folks Navigating from http://swiki.krampe.se/gjallar seems the project is non working No downloads No lists Any help ? Edgar

Oct. 11, 2011