Also useful for "quick and dirty" debugging with concurrent processes:
OSProcess trace: 'my debugging note' This prints to console, identifying the process, receiver, method, and whatever additional notes you may want to add. Dave On Wed, Apr 03, 2019 at 07:34:22AM +0200, Tudor Girba wrote: > Instead of printing, you can also use Beacon. We actually developed Beacon > specifically to be able to debug a parallel distributed system. > > Cheers, > Doru > > > On Apr 2, 2019, at 11:56 PM, Ben Coman <b...@openinworld.com> wrote: > > > > > > On Tue, 2 Apr 2019 at 23:36, ducasse <steph...@netcourrier.com> wrote: > > I???m inherently race condition incompatible and just avoid concurrent > > programming because I???m too dull on this. > > > > I've solved a few Pharo race conditions before, so just a tip (that you > > maybe already know). > > You can't troubleshoot a race condition by standard debugging, because it > > alters the timing. > > Best that I've done before is resorting to plain old print-line tracing > > between every line of the suspect code, > > or the equivalent threadsafe collection if its not a hard crash. > > e.g.... > > someMethod > > threadsafeCollection add: "methodname-A" , testCondition > > original method line 1 > > threadsafeCollection add: "methodname-B", testCondition > > original method line 2 > > threadsafeCollection add: "methodname-C", testCondition > > > > and then looking for cyclic patterns in that data and breaks in those > > patterns. > > > > I can have a look in a few weeks. Right now working 13 hour days to the > > end of the week > > and then vacationing in China for 10 days. > > > > -- > www.feenk.com > > "Sometimes the best solution is not the best solution." >
