Persistant applications

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Persistant applications

Ian Bartholomew-18
This is a bit strange so I'd appreciate it if somebody could see if they
are getting the same thing and would also be receptive to any
suggestions as to why it's happening and how to get rid of it.

I've uploaded a demo package (created using an unmodified 5.1.3) to

http://www.idb.me.uk/files/persist.zip  (1.3K)

It is about as simple as it could be.  A single Shell subclass (Test)
with no modifications and a SessionManager (TestSM) that has a #main
that starts up Test. When deployed the package should produce an
executable named Test.exe.

On my XP machine when I start up Test.exe everything works as expected
(not that much _is_ expected).  I can then close the app and the shell
disappears.  The _problem_ is that when I look in Task Manager I can
still see the application listed as active and it doesn't seem go
however long I leave it.  The _strange_ thing is that if I open up
Windows Explorer (click on My Documents for example) then Test.exe
immediately disappears from the task list.

On my Win2000 box almost the same thing happens but with the difference
that opening explorer doesn't clear the app from the task list.  I have
also noticed that it has disappeared on it's own a couple of times - but
only after a long delay.

On both machines telling TaskManager to end the process works correctly.

Any suggestions?

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.


Reply | Threaded
Open this post in threaded view
|

Re: Persistant applications

Bill Schwab-2
Ian,

> This is a bit strange so I'd appreciate it if somebody could see if they
> are getting the same thing and would also be receptive to any
> suggestions as to why it's happening and how to get rid of it.

I _think_ it's a known problem.


> On my XP machine when I start up Test.exe everything works as expected
> (not that much _is_ expected).  I can then close the app and the shell
> disappears.  The _problem_ is that when I look in Task Manager I can
> still see the application listed as active and it doesn't seem go
> however long I leave it.  The _strange_ thing is that if I open up
> Windows Explorer (click on My Documents for example) then Test.exe
> immediately disappears from the task list.

The above might weaken my argument, but...

> On my Win2000 box almost the same thing happens but with the difference
> that opening explorer doesn't clear the app from the task list.  I have
> also noticed that it has disappeared on it's own a couple of times - but
> only after a long delay.
>
> On both machines telling TaskManager to end the process works correctly.
>
> Any suggestions?

This sounds like a problem that appeared in (IIRC) 5.1.  The shutdown
behavior changed to the point that one must now explicitly tell the session
manager to exit; the (IMHO superior) option of leaving things to #keepAlive
no longer works, at least not reliably.  Check the archives for things like
shutdown and #keepAlive, and see if the discussion matches your problem.
Appologies if I am missing the point.

BTW, thanks for revised chunk browser.  It worked perfectly!

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Persistant applications

Chris Uppal-3
In reply to this post by Ian Bartholomew-18
Ian,

> This is a bit strange so I'd appreciate it if somebody could see if they
> are getting the same thing and would also be receptive to any
> suggestions as to why it's happening and how to get rid of it.

It seems to die properly for me.  I've tried it on both an XP and a W2K box.

I don't think that OA are recommending relying on the #keepAlive mechanism for
automatically closing down applications, although it often *does* work.

I can't explain why looking in Windows Explorer should make the app go away,
but it reminds me of the way that this XP box will tend to stall when opening a
shared folder on another machine, but then -- completely reliably -- will
unhang itself when I open any folder on the local machine.  (One of the joys of
WinXP ;-)

Possibly there's some sort of glitch that's stopping your app seeing an idle
event, so that it doesn't realise that it's time to check whether any windows
are still open, and so doesn't die when it should.  And then some (additional)
Windows strangeness makes opening another window send it another idle event to
your app, at which it checks again and dies belatedly.  But that's pure
speculation...

    -- chris


Reply | Threaded
Open this post in threaded view
|

Re: Persistant applications

Ian Bartholomew-18
In reply to this post by Bill Schwab-2
Bill and Chris,

Thanks for the prompt reply.  You were both spot on with the reason and
adding the workaround that Christopher Demers posted  last year (adding
SessionManager current isRuntime ifTrue: [SessionManager current exit].
to #onViewClosed) fixed it straight away.

I wish I'd asked earlier :-).  I first noticed it in with a deployed app
that kept crashing another app (it couldn't close because the Dolphin
app that hadn't disappeared was keeping a file open).  The Dolphin app
used IFileSystem (and we all know how I feel about COM) and also the
latest RichEdit so I blamed them first and have spent quite a bit of
time today removing those parts bit - by - bit, only to find they were
innocent.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.


Reply | Threaded
Open this post in threaded view
|

Re: Persistant applications

Blair McGlashan
In reply to this post by Bill Schwab-2
"Bill Schwab" <[hidden email]> wrote in message
news:c259f8$10c2$[hidden email]...
> Ian,
>
> > This is a bit strange so I'd appreciate it if somebody could see if they
> > are getting the same thing and would also be receptive to any
> > suggestions as to why it's happening and how to get rid of it.
>
> I _think_ it's a known problem.

We intend to fix this in PL4 for Win2K, XP, 2003, etc, but not Win98. The
history of the issue is a long one, but the shutdown delay (for it is a
delay, even if that delay can sometimes run into minutes) is caused by a
workaround to a bug in the implementation of the GetQueueStatus() on Windows
98. I have spent a number of hours investigating this issue already, and I
haven't been able to find a way of fixing this for Windows 98 without
reintroducing previous issues that were frankly more significant.

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: Persistant applications

Blair McGlashan
"Blair McGlashan" <[hidden email]> wrote in message
news:c26pnp$1pv1rf$[hidden email]...
> "Bill Schwab" <[hidden email]> wrote in message
> news:c259f8$10c2$[hidden email]...
> > Ian,
> >
> > > This is a bit strange so I'd appreciate it if somebody could see if
they
> > > are getting the same thing and would also be receptive to any
> > > suggestions as to why it's happening and how to get rid of it.
> >
> > I _think_ it's a known problem.
>
> We intend to fix this in PL4 for Win2K, XP, 2003, etc, but not Win98. ....

Since I've been intending to get around to this for a while, I've prepared
the patch and placed it at:

http://www.object-arts.com/Lib/Update/Dolphin/5.1/1451.st

This should fix delayed lazy shutdown of applications on all but Win98/Me
hosts. It will install on the latter, but essentially preserves the existing
behaviour for those platforms. For 2k, XP, & 2k3 it replaces the idle loop
message detection mechanism with that in the original 5.1 release before it
was modified for #1272.

Please backup your image before installing this patch in caes of any
problems.

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: Persistant applications

Ian Bartholomew-18
Blair,

> Since I've been intending to get around to this for a while, I've
> prepared the patch and placed it at:

Thanks.  I've just redeployed my app with your patch in place and it now
disappears from the task list straight away.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.


Reply | Threaded
Open this post in threaded view
|

Re: Persistant applications

Ian Bartholomew-18
In reply to this post by Blair McGlashan
Blair,

> This should fix delayed lazy shutdown of applications on all but
> Win98/Me hosts

I've started seeing delays in shutting down again (on XP) and have
tracked it down to the prompt to save changes that I use if the app has
unsaved changes.  As an example I created a package as before (a single
RuntimeSessionManager subclass and a Shell subclass with a view but
nothing else).  I then added two methods...

createSchematicWiring
    super createSchematicWiring.
    self
        when: #closeRequested:
        send: #onCloseRequested:
        to: self

onCloseRequested: boolValueHolder
    MessageBox
        confirm: 'Save changes'
        onYes: [boolValueHolder value: true]
        onNo: [boolValueHolder value: true]
        onCancel: [boolValueHolder value: false].
    ^boolValueHolder value

When I deploy and run the app then I get the long delay  before it
disappears from the task list (although the trick of opening Explorer
still works!).

This is on a 5.1.3 image with 1451 installed.  If I comment out the
#createSchematicWiring code then it always disappears from the task list
almost immediately.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.


Reply | Threaded
Open this post in threaded view
|

Re: Persistant applications

Bill Schwab-2
Ian,

> When I deploy and run the app then I get the long delay  before it
> disappears from the task list (although the trick of opening Explorer
> still works!).
>
> This is on a 5.1.3 image with 1451 installed.  If I comment out the
> #createSchematicWiring code then it always disappears from the task list
> almost immediately.

Message boxes sometimes cause problems, though IIRC, the complaint has
usually been premature shutdown rather than a delay.  Look for #taskModal in
the archives.

Did you use this prompt prior to applying 1451?  Do you have a win2k box
available to see if it's unique to XP?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Persistant applications

Ian Bartholomew-18
Bill,

> Message boxes sometimes cause problems, though IIRC, the complaint has
> usually been premature shutdown rather than a delay.  Look for
> #taskModal in the archives.

I recall similar difficulties in the past but the problem I was seeing
was so close to the original error (even to the extent that opening up
an Explorer view would clear it) I thought it worth mentioning.  Now I
know it's happening I just have to remember to save before closing the
shell so I don't really need to "fix" it. :-)

> Did you use this prompt prior to applying 1451?

Yes, but I wouldn't have known if it, specifically, caused a problem
then - it would have given the same result as the original (now fixed)
problem.

> Do you have a win2k box available to see if it's unique to XP?

Just tried it.  I get the same thing with the exception that opening up
an Explorer window doesn't clear it - I have to end the task in the Task
Manager.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.


Reply | Threaded
Open this post in threaded view
|

Re: Persistant applications

Blair McGlashan
Ian

You wrote in message news:c2g4be$1rvfmd$[hidden email]...

>
> > Message boxes sometimes cause problems, though IIRC, the complaint has
> > usually been premature shutdown rather than a delay.  Look for
> > #taskModal in the archives.
>
> I recall similar difficulties in the past but the problem I was seeing
> was so close to the original error (even to the extent that opening up
> an Explorer view would clear it) I thought it worth mentioning.  Now I
> know it's happening I just have to remember to save before closing the
> shell so I don't really need to "fix" it. :-)

I would particularly recommend using an explicit exit in this case, just as
the development system does.

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: Persistant applications

Ian Bartholomew-18
Blair,

> I would particularly recommend using an explicit exit in this case,
> just as the development system does.

OK, thanks.  I've had another read of some of the messages on the
subject and now appreciate why the belts and braces approach is probably
best.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.