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.