On 16 April 2013 16:39, Goubier Thierry <thierry.goub...@cea.fr> wrote: > Le 16/04/2013 16:29, Igor Stasenko a écrit : > >> On 16 April 2013 16:27, Goubier Thierry <thierry.goub...@cea.fr> wrote: >>> >>> Le 16/04/2013 16:12, Igor Stasenko a écrit : >>> >>>> On 16 April 2013 15:47, kilon <theki...@yahoo.co.uk> wrote: >>>>> >>>>> >>>>> Thats awesome but I cant open my pharo image anymore , I dont mind >>>>> starting >>>>> from a new image and reinstalling everything >>>>> but I was wondering if there is a way to recover all that or am I >>>>> screwed >>>>> ? >>>>> :) >>>>> >>>> You have a talent at screwing things up :) >>>> But your feedback is invaluable, which helping to spot details , which >>>> obvious to me but not for a newcomer. >>>> >>>> Yeah, concerning screwed image: in such cases i usually run it with VM >>>> which does not includes NativeBoost, then it fails with error.. and >>>> you can close morphs/debugger save image and can continue work with >>>> Cog VM.. it is , of course not always works, because it depends how >>>> badly things screwed up. :) >>> >>> >>> >>> Igor, could you add code to start the session without gui, run a bit of >>> smalltalk code to destroy the dangling surfaces and save again ? >>> >>> It would probably save the day a few times :) >>> >> yes, i am already thinking on it. >> >> The thing which i want to do is to put a session check in #drawDuring: >> method, >> to check if surface is still valid. >> And if its not, then shoot the caller :) > > > We don't have a framework for handling external resources tracking across > sessions, wher you can specify a reopen/destroy policy ? >
Well, NativeBoost has some bits for supporting session-aware code. The problem is that management of external resources almost always specific to what you using... During my development of NB i identified some general patterns, which then shaped into implementation of concrete service classes. We're planning to move some parts of it out of NB to Kernel. But that is the road to walk. > How are servers doing it? They have to close connections on session close > and reopen them at start, no? Why not using the same code for Athens and > recreate the surface on session start or fail (without segfault). > Well, the question is always at which level you should do it. How you can avoid checking every single external resource handle every time you trying to use it, and instead introduce check at higher levels (at root entry to your model) because checking costs resources. But because different frameworks employing different models, it is hard to find one, which is so general and fits all. > Ah yes, shooting the caller is fine if we restart on a system without the > ability to create the surface... What do you think of throwing an exception? > That's what i going to do for the starting. But Athens surface is really low level. And introducing some auto-management will be a mistake. The code which should recreate surface upon image restart should be in user's code, because we cannot predict how new session is different comparing to previous one.. User may decide to choose different backend in new session, reload some files from disk etc... > Thierry > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des Systèmes Temps Réel Embarqués > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > -- Best regards, Igor Stasenko.
