You are mixing 3 different aspects: - how to update a UI from a background process - how to maintain a background process over image save/open - how to communicate between the 2 Safe UI updating has to happen using #step or #defer: and should be quick/short as not to block the UI. Although processes survive over image save/open (provided they did not become garbage), this is dangerous as they come up immediately (too soon) and will probably hold external resources (files/sockets/..) that will have changed (and result in a crash). It is better to manage this explicitly using #startUp and #shutDown. Communication between the 2 should be protected using a semaphore. Here is an example of a 'file watcher', a little window that shows the first line of a specific file, updating it every 3 seconds (silly and too resource intensive, it is just a demo). You can edit the file manually to modify the contents of the first line and see it being picked up in Pharo (within 3 seconds). Here is the code as 1 file/class in '_UnpackagedPackage': See the class side #initialize for the #startUp and #shutDown registration, sent to all instances as #start and #stop (a bit rude but good enough for the demo). Instance side #initialize sets up the mutex that gets used in the #firstLine and #firstLine: accessors. The actual process is in #run which calls #updateFirstLine The UI updating is in #step which calls #updateFileLineDisplay Subscribing to MorphDeleted via the announcer allows for the process to stop when the window closes. The file watcher window and process survive an image save/open (i.e. they keep on working). HTH, Sven
On 3 Jun 2017, at 15:44, horrido <horrido.hobbies@gmail.com> wrote:
Okay, let me explain my application...
It displays a Morphic window containing lines of information that are updateable in real time on a periodic basis. As I indicated in the original post, the code skeleton is basically:
initA a := ((StringMorph contents: '####') color: Color white) position: (0@0). m addMorph: a
initialize f := Form fromFileNamed: 'hot_air_balloon_mysticmorning.jpg'. m := ImageMorph new. m form: f. self initA. m openInWindowLabeled: 'Cranky'. delay := (Delay forSeconds: 5). [ [ true ] whileTrue: [ a contents: 0 asString. delay wait ] fork
Imagine that #initA creates many such StringMorphs, each displaying a different kind of information.
In the endless loop, imagine that instead of 'a contents: 0 asString', I'm updating all of the StringMorphs I created in #initA.
The need to do this in a separate thread is to prevent Pharo from being completely frozen during the 'delay wait', which is practically all the time!
Now, I did try Hilaire's suggestion to use Morphic's step protocol instead. But in my test scenario of closing the app/saving and exiting the image/restarting the image, repeatedly (in may take 10-20 times), it still causes the occasional segmentation fault.
So if the problem is updating a structure in the main thread from another process, then why did Hilaire's suggestion not solve the problem?
It seems to me, then, either way, it's an issue of multithreading...whether my way or Hilaire's way.
Sven Van Caekenberghe-2 wrote
Hi Horrido,
It is very hard to follow what you are exactly doing or trying to do.
Here is the simplest example I can think of that updates something in Morphic on a regular basis.
StringMorph subclass: #MyClock instanceVariableNames: '' classVariableNames: '' package: '_UnpackagedPackage'
MyClock>>#initialize super initialize. self updateClock
MyClock>>#step self updateClock
MyClock>>#updateClock self contents: Time now printString
MyClock class>>#open "self open"
^ self new openInWindow
This inherits #stepTime as 1 second. If I open such a window and save my image, it is still there when the image is restarted, with the clock still working.
Updating (data structures in) the main UI process from another process is dangerous. Saving such constructs is even more dangerous.
HTH,
Sven
On 2 Jun 2017, at 15:54, horrido <
horrido.hobbies@
> wrote:
Sorry, I could be mistaken. I just checked my notes. The *0 asString* test failed once, but I've not been able to replicate it. I might've been working with an unclean image.
So perhaps it is related to Morphic, after all.
Yup, they all fail. Interesting that
0 asString
horrido wrote * *
fails. This means it has NOTHING to do with Morphic (or Morphic being thread-unsafe).
Ben Coman wrote
On Wed, May 31, 2017 at 10:23 PM, horrido <
horrido.hobbies@
> wrote:
Can you try a few other variations... [ [ true ] whileTrue: [ 0 asString. delay wait ] fork. [ [ true ] whileTrue: [ a contents: '0'. delay wait ] fork. [ [ true ] whileTrue: [ a contents: '0'. ] forkAt: 20.
cheers -ben
-- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948984.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4949166.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.