Hi,
I was playing within Squeak, on a win2k laptop, with an image I had shared over a network. I then suspended the laptop, with Squeak running, and brought the machine back to life some time later. I started to get primitive errors along the lines of write's failing. This was a felt a bit odd for a while as I was only writing to the Transcript. When I tried to save my image, however, I realised that it was probably due to suspending the machine and I was unable to save the image. I tried to find a way of saving to the local drive but wasn't able to figure that out. I didn't have anything particularly serious to lose to I quit the image.
I was wondering if this was a known issue, or has cropped up before?
It seems a bit of a daft thing to have done, in retrospect, but it would be nice to be able to fix this or have some work around.
Any thoughts much appreciated
Cheers
Mike
On Wednesday 11 September 2002 04:39 am, Michael Roberts wrote (about Win2K):
I was playing within Squeak, on a win2k laptop, with an image I had shared over a network. I then suspended the laptop, with Squeak running, and brought the machine back to life some time later. I started to get primitive errors along the lines of write's failing.
And yesterday, Scott Jaderholm wrote (about WinCE):
If I have squeak running on an Ipaq when the display timesout after
so
long of no use, then when I turn it back on squeak does not redraw.
Sounds like we're missing some notification from WinNT/WinCE...
But is there some way to tell Squeak about the need to update sockets (say)? Or could this be done in the Sockets plugin?
Ned,
Sounds like we're missing some notification from WinNT/WinCE...
To me, it sounds as if MS should get its act together. If it doesn't send a notification to the window that's been woken up after a sleep to redraw itself, what do you expect Squeak to do?! If it isn't capable of getting the network connections back up what do you expect Squeak to do?! Test on each every access if the connection is still there and if not try to restart Windows?! (hey, now that's an idea ;-)))
Cheers, - Andreas
On Wednesday 11 September 2002 07:50 am, Andreas Raab wrote:
Ned,
Sounds like we're missing some notification from WinNT/WinCE...
To me, it sounds as if MS should get its act together. If it doesn't send a notification to the window that's been woken up after a sleep to redraw itself, what do you expect Squeak to do?! If it isn't capable of getting the network connections back up what do you expect Squeak to do?! Test on each every access if the connection is still there and if not try to restart Windows?! (hey, now that's an idea ;-)))
Cheers,
- Andreas
What about the WM_POWERBROADCAST message (at least for non-WinCE apps)? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/power/base/...
From its docs:
LRESULT CALLBACK WindowProc( HWND hwnd, // handle to window UINT uMsg, // WM_POWERBROADCAST WPARAM wParam, // power-management event LPARAM lParam // function-specific data );
Parameters
hwnd Handle to window. uMsg WM_POWERBROADCAST message identifier. wParam Power-management event. This parameter can be one of the following events.
Event Meaning
PBT_APMBATTERYLOW Battery power is low.
PBT_APMOEMEVENT OEM-defined event occurred.
PBT_APMPOWERSTATUSCHANGE Power status has changed.
PBT_APMQUERYSUSPEND Request for permission to suspend.
PBT_APMQUERYSUSPENDFAILED Suspension request denied.
PBT_APMRESUMEAUTOMATIC Operation resuming automatically after event.
PBT_APMRESUMECRITICAL Operation resuming after critical suspension.
PBT_APMRESUMESUSPEND Operation resuming after suspension.
PBT_APMSUSPEND System is suspending operation.
lParam Function-specific data. For most events, this parameter is reserved and not used.
However, if wParam is one of the resume events (PBT_APMRESUME*), the lParam parameter can specify the PBTF_APMRESUMEFROMFAILURE flag. This flag indicates that a suspend operation failed after the PBT_APMSUSPEND event was broadcast.
Return Values
Return TRUE to grant a request.
Return BROADCAST_QUERY_DENY to deny a request.
Requirements
Windows NT/2000/XP: Included in Windows NT 4.0 and later. Windows 95/98/Me: Included in Windows 95 and later. Header: Declared in Winuser.h; include Windows.h.
Ned,
What about the WM_POWERBROADCAST message (at least for non-WinCE apps)?
You missed my point entirely or perhaps I didn't make it clear enough. Of course there are ways of getting notified (there always are) in the VM about a startup but what should the VM do?! It doesn't know enough about the resources associated (like, for example, what files are open and where the files come from) nor does it know about how to handle this situation in the context of some application or other. E.g., even assuming that we'd be enumerating the entire object memory to find all the file handles, do we actually know which ones to reopen?! Do we know how to handle failure situations?! Do we know if it's appropriate to reopen a network connection or not?! At the VM level, we just don't. And that's the problem. So the best I could eventually do is to pass some notification up to the Squeak level. But even then it's not always clear how to handle the situation. It would be much simpler if you could rely on the OS to handle these things for you if it pulls away the carpet under your feets ;-)
Cheers, - Andreas
Andreas,
how to handle the situation. It would be much simpler if you could rely on the OS to handle these things for you if it pulls away the carpet under your feets ;-)
Take my advice, don't rely too much on the OS (got it ;-)
Otherwise, don't stand on the carpet ;-)
Cheers,
PhiHo.
----- Original Message ----- From: "Andreas Raab" Andreas.Raab@gmx.de To: squeak-dev@lists.squeakfoundation.org Sent: Wednesday, September 11, 2002 1:07 PM Subject: RE: Win Squeak needs to know about waking up! (Re: Laptop suspending and network drives)
Ned,
What about the WM_POWERBROADCAST message (at least for non-WinCE apps)?
You missed my point entirely or perhaps I didn't make it clear enough. Of course there are ways of getting notified (there always are) in the VM about a startup but what should the VM do?! It doesn't know enough about the resources associated (like, for example, what files are open and where the files come from) nor does it know about how to handle this situation in the context of some application or other. E.g., even assuming that we'd be enumerating the entire object memory to find all the file handles, do we actually know which ones to reopen?! Do we know how to handle failure situations?! Do we know if it's appropriate to reopen a network connection or not?! At the VM level, we just don't. And that's the problem. So the best I could eventually do is to pass some notification up to the Squeak level. But even then it's not always clear how to handle the situation. It would be much simpler if you could rely on the OS to handle these things for you if it pulls away the carpet under your feets ;-)
Cheers,
- Andreas
On Wednesday 11 September 2002 10:07 am, Andreas Raab wrote:
Ned,
What about the WM_POWERBROADCAST message (at least for non-WinCE apps)?
You missed my point entirely or perhaps I didn't make it clear enough. Of course there are ways of getting notified (there always are) in the VM about a startup but what should the VM do?! It doesn't know enough about the resources associated (like, for example, what files are open and where the files come from) nor does it know about how to handle this situation in the context of some application or other. E.g., even assuming that we'd be enumerating the entire object memory to find all the file handles, do we actually know which ones to reopen?! Do we know how to handle failure situations?! Do we know if it's appropriate to reopen a network connection or not?! At the VM level, we just don't. And that's the problem. So the best I could eventually do is to pass some notification up to the Squeak level. But even then it's not always clear how to handle the situation. It would be much simpler if you could rely on the OS to handle these things for you if it pulls away the carpet under your feets ;-)
I agree that the OS shouldn't change the state of the system when the power comes back up, if it can manage not to. But Squeak _could_ be more power-aware, especially for PDAs.
We're in a position in the VM to actually remember sockets and file handles.
We can hear that the power's going down from the OS and refuse to power down if we have a network file share open that isn't cached locally.
We can hear that the power came back up and we need to repaint the window.
We can notify the OS that we're actually busy when we are doing something so it doesn't power us down.
We could close sockets and remote file handles on power-down. We're already detecting attempted operations on closed handles and raising exceptions. We could if we wanted, remember that we closed the files because of power-down.
As you point out, handling such errors is the concern of the application, but we could at least raise a recognizable exception to let the application know what happened: i.e. the difference between "tried to read from a file that was already intentionally closed (software error)" and "tried to read from a file that was closed on power down (not a software error)".
There are guidelines here for dealing with power management in Win2K: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnhdware/ht...
Hi Ned,
I agree that the OS shouldn't change the state of the system when the power comes back up, if it can manage not to. But Squeak _could_ be more power-aware, especially for PDAs.
I don't doubt this (thus my argument for pulling up the event to image level) but do you *really* want to implement all of the stuff below in the VM?! I mean...
We're in a position in the VM to actually remember sockets and file handles.
Why should we? This information is in Squeak already so why duplicate it?
We can hear that the power's going down from the OS and refuse to power down if we have a network file share open that isn't cached locally.
Why should we? It may be perfectly fine to close and power down in most situations.
We can hear that the power came back up and we need to repaint the window.
That we could do ... although Squeak could too given the information so why bother?!
We can notify the OS that we're actually busy when we are doing something so it doesn't power us down.
How could we?! What defines that "we're actually busy" on the VM level?! A call to ioRelinquishProcessorBlaBla?! Happens all the time all over the places.
We could close sockets and remote file handles on power-down. We're already detecting attempted operations on closed handles and raising exceptions. We could if we wanted, remember that we closed the files because of power-down.
Same issue as above. The information is available at the Squeak level so why bother second-guessing at what's actually happening?!
As you point out, handling such errors is the concern of the application, but we could at least raise a recognizable exception to let the application know what happened: i.e. the difference between "tried to read from a file that was already intentionally closed (software error)" and "tried to read from a file that was closed on power down (not a software error)".
Right. But I think any such mechanism should not be handled by the VM. If a file handle was closed and you ship the image containing it to another platform, then suspend it and resume and try to read from the suspended file handle ... why should the VM assume that this handle must be invalid due to resuming?! Much better just to tell Squeak "hey, we wanna get to sleep" and leave it up to it to handle the situation. Then you can implement even more esoteric solutions than Windows must be using ;-))))
Cheers, - Andreas
On Wednesday 11 September 2002 04:27 pm, Andreas Raab wrote:
Much better just to tell Squeak "hey, we wanna get to sleep" and leave it up to it to handle the situation. Then you can implement even more esoteric solutions than Windows must be using ;-))))
What kind of callback into Squeak can we actually manage? The only ones I can think of at this moment are:
* signal a Semaphore to tell a previously-blocked Process that it needs to find out what kind of event actually happened, or
* pass an event up along with the keyboard/mouse events
I'm following this thread with interest and was wondering if there was anything, currently, that could be executed in a workspace to perform an emergency recovery of sorts. Is it possible to re-initialise what's required to save the image to a local disk? I'm happy to test any suggestions.
Cheers
Mike
On Thursday 12 September 2002 01:51 am, Michael Roberts wrote:
I'm following this thread with interest and was wondering if there was anything, currently, that could be executed in a workspace to perform an emergency recovery of sorts. Is it possible to re-initialise what's required to save the image to a local disk? I'm happy to test any suggestions.
Cheers
Mike
Perhaps something like this:
newName := 'c:\temp\squeak'. Smalltalk saveChangesInFileNamed: (Smalltalk fullNameForChangesNamed: newName); saveImageInFileNamed: (Smalltalk fullNameForImageNamed: newName); snapshot: false andQuit: true.
On Thu, Sep 12, 2002 at 08:46:14AM -0700, Ned Konz wrote:
Perhaps something like this:
newName := 'c:\temp\squeak'. Smalltalk saveChangesInFileNamed: (Smalltalk fullNameForChangesNamed: newName); saveImageInFileNamed: (Smalltalk fullNameForImageNamed: newName); snapshot: false andQuit: true.
Hi,
I have been testing this code and I have a questions and observations.
1) I tried to recreate the problem with a win xp pro pc running an image served from a win2k server. After performing a suspend cycle, the drives came back fine. I didn't try harder to get this not to work following this simple test. I don't know whether the xp code is better at power management regarding drives/files etc.
2) More importantly, the files saved ignore the drive and directory specified in the string
printing Smalltalk fullNameForChangesNamed: 'c:\temp\squeak-test' gives 'squeak-test.changes'
looking at the first line of that method newName _ FileDirectory baseNameFor: aName asFileName.
aName asFileName gets evaluated first.
digging deeper
String>>asFileName FileDirectory class>>checkName: self fixErrors: true FileDirectory class>>localNameFor:
This last method strips the path off.
Therefore, I was wondering if SystemDictionary>>fullNameForChangesNamed was intended to allow the path through or whether this is a bug? Is String>>asFileName intended to strip the path off? Apologies if I have I missed something obvious!
This is on Squeak3.2 #4956.
Cheers,
Mike
You missed my point entirely or perhaps I didn't make it clear enough. Of course there are ways of getting notified (there always are) in the VM about a startup but what should the VM do?!
I'll point out the mac vm does take action on sleep/wake for sockets. However some of this has changed between os 8.x and 9.x let alone 10.x , testing this was a bear and I've not looked at it for years now.
It was more a preventive action because we'd get notified that all our socket structures were being invalidated and we needed to set some flags otherwise when squeak wakes up and attempts socket interact then it would die attempting to use bogus sockets handles. I think starting in os-9 they keep all the structures now and *maybe* on a wakeup you continue, but I've not verified that.
Ah, also if someone changes the IP address of the machine while running a squeak server, dumb idea, notifications of this flow too.
But lets consider this as a broader topic, not only wake/sleep should be passed up, also quit for example has been raised from time to time as an issue.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
On Wednesday 11 September 2002 07:50 am, Andreas Raab wrote:
Ned,
Sounds like we're missing some notification from WinNT/WinCE...
To me, it sounds as if MS should get its act together. If it doesn't send a notification to the window that's been woken up after a sleep to redraw itself, what do you expect Squeak to do?!
And under Windows/CE you can register to get a notification: http://www.microsoft.com/mobile/developer/technicalarticles/pwrnotification....
On Wednesday 11 September 2002 07:50 am, Andreas Raab wrote:
Ned,
Sounds like we're missing some notification from WinNT/WinCE...
To me, it sounds as if MS should get its act together. If it doesn't send a notification to the window that's been woken up after a sleep to redraw itself, what do you expect Squeak to do?!
It looks like WinCE returns EV_POWER from the (blocking) WaitCommEvent() API call on power-resume; we could have a separate thread that would just wait for this and signal a semaphore.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceseril/ht...
It's not clear to me which WinCE variants support WM_POWERBROADCAST, but apparently some do.
And some also apparently send a WM_KEYUP (for the power key?) on power-up.
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
John M McIntosh -
Michael Roberts -
Ned Konz -
PhiHo Hoang