Hello,
I'm running the following program with two simple processes (the main one and a forked process): [ | i | i := 0. [ true ] whileTrue: [ i := i + 1. i displayNl. (Delay forSeconds: 1) wait ] ] fork. [ true ] whileTrue: [ Processor yield ] I was expecting these two processes to run indefinitely, but the program hangs after printing a few lines: 1 2 3 And then I have to interrupt it. I'm wondering if there's something basic I'm missing here. Maybe I don't understand how "Process yield" works, but I thought it was just going to suspend the current process and let the forked process run. Any help is appreciated, Quenio _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
> On 20. Jul 2019, at 21:36, Quenio dos Santos <[hidden email]> wrote: Hi! > > And then I have to interrupt it. > > I'm wondering if there's something basic I'm missing here. Maybe I don't > understand how "Process yield" works, but I thought it was just going to > suspend the current process and let the forked process run. Can you try with the master branch? I suspect some known (and fixed) undefined behavior in 3.2.5. holger _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
I haven't been able to compiler master on MacOS. I installed GCC and
configured as follows, but it still seems to be using CLANG: $ configure --prefix=/usr/local/Cellar/gcc/9.1.0 --with-gmp=/usr/local/Cellar/gcc/9.1.0 ... $ make ... cd packages/net && /Applications/Xcode.app/Contents/Developer/usr/bin/make CC gnutls-wrapper.o CCLD gnutls-wrapper Undefined symbols for architecture x86_64: "_gnutls_alert_send", referenced from: _main in gnutls-wrapper.o "_gnutls_alert_send_appropriate", referenced from: _main in gnutls-wrapper.o "_gnutls_anon_allocate_client_credentials", referenced from: _main in gnutls-wrapper.o "_gnutls_anon_free_client_credentials", referenced from: _main in gnutls-wrapper.o "_gnutls_bye", referenced from: _main in gnutls-wrapper.o "_gnutls_certificate_allocate_credentials", referenced from: _main in gnutls-wrapper.o "_gnutls_certificate_free_credentials", referenced from: _main in gnutls-wrapper.o "_gnutls_credentials_set", referenced from: _main in gnutls-wrapper.o "_gnutls_deinit", referenced from: _main in gnutls-wrapper.o "_gnutls_error_is_fatal", referenced from: _main in gnutls-wrapper.o "_gnutls_global_deinit", referenced from: _main in gnutls-wrapper.o "_gnutls_global_init", referenced from: _main in gnutls-wrapper.o "_gnutls_handshake", referenced from: _main in gnutls-wrapper.o "_gnutls_init", referenced from: _main in gnutls-wrapper.o "_gnutls_perror", referenced from: _main in gnutls-wrapper.o "_gnutls_record_recv", referenced from: _main in gnutls-wrapper.o "_gnutls_record_send", referenced from: _main in gnutls-wrapper.o "_gnutls_set_default_priority", referenced from: _main in gnutls-wrapper.o "_gnutls_transport_set_ptr", referenced from: _main in gnutls-wrapper.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [gnutls-wrapper] Error 1 make[2]: *** [NetClients.star] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 On Sat, Jul 20, 2019 at 12:00 PM Holger Freyther <[hidden email]> wrote: > > > > On 20. Jul 2019, at 21:36, Quenio dos Santos <[hidden email]> > wrote: > > > Hi! > > > > > > And then I have to interrupt it. > > > > I'm wondering if there's something basic I'm missing here. Maybe I don't > > understand how "Process yield" works, but I thought it was just going to > > suspend the current process and let the forked process run. > > Can you try with the master branch? I suspect some known (and fixed) > undefined > behavior in 3.2.5. > > > > holger help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Quenio dos Santos
Hi Quenio,
I can't speak for GNU Smalltalk, but yield in general is a tricky business, and does often not mean what one might think. A good way of thinking of yield is: "Hi scheduler, I'm not done yet, but if you have something important to do, I will yield now". In particular, yield MAY be a no-op, so never put it in a busy-wait loop. Anyways, puting a delay in the main process makes the two processes take turns on the cpu. This may be a bug, a feature, or per design, I have really no idea. Just don't ever put yield in a busy-wait loop, and everyone will be fine. :-) /Tommy _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Thanks for the explanation, Tommy.
I did try it with a delay instead of yielding in the main process, but got the same hanging behavior. I was looking at the implementation of Delay, and suspect the non-synchronized queue used there might be causing this problem. On Sat, 20 Jul 2019 at 17:35 Tommy Pettersson <[hidden email]> wrote: > Hi Quenio, > > I can't speak for GNU Smalltalk, but yield in general is a tricky business, > and does often not mean what one might think. A good way of thinking of > yield is: "Hi scheduler, I'm not done yet, but if you have something > important to do, I will yield now". In particular, yield MAY be a no-op, so > never put it in a busy-wait loop. > > Anyways, puting a delay in the main process makes the two processes take > turns on the cpu. This may be a bug, a feature, or per design, I have > really no idea. Just don't ever put yield in a busy-wait loop, and > everyone will be fine. :-) > > /Tommy > > _______________________________________________ > help-smalltalk mailing list > [hidden email] > https://lists.gnu.org/mailman/listinfo/help-smalltalk > help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
If it's not working with a delay in the main process it sounds like a bug.
What if you put a counter in the main process and print it as well, does the main process stop too, or is it just the forked process? Btw, on my Linux machine your original example works the way you expect. I get the output: 1 2 3 4 5 6 7 ... and so on, until I interrupt it. Both with v3.2.5 and current master branch. /Tommy _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
It hangs as well when I put the counter on the main process with a delay.
i := 0. [ true ] whileTrue: [ i := i + 1. i displayNl. (Delay forSeconds: 1) wait. ] $ gst counter.st 1 2 3 On Sun, Jul 21, 2019 at 8:20 AM Tommy Pettersson <[hidden email]> wrote: > If it's not working with a delay in the main process it sounds like a bug. > What if you put a counter in the main process and print it as well, does > the main process stop too, or is it just the forked process? > > Btw, on my Linux machine your original example works the way you expect. I > get the output: > > 1 2 3 4 5 6 7 ... and so on, until I interrupt it. > > Both with v3.2.5 and current master branch. > > /Tommy > help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
I'm running gst 3.2.5 on Ubuntu 18.04.2 LTS (bionic) and it works fine there.
-----Original Message----- From: help-smalltalk <help-smalltalk-bounces+mdbratch=[hidden email]> On Behalf Of Quenio dos Santos Sent: Sunday, July 21, 2019 11:04 AM To: Tommy Pettersson <[hidden email]> Cc: [hidden email] Subject: Re: [Help-smalltalk] Process & Fork It hangs as well when I put the counter on the main process with a delay. i := 0. [ true ] whileTrue: [ i := i + 1. i displayNl. (Delay forSeconds: 1) wait. ] $ gst counter.st 1 2 3 On Sun, Jul 21, 2019 at 8:20 AM Tommy Pettersson <[hidden email]> wrote: > If it's not working with a delay in the main process it sounds like a bug. > What if you put a counter in the main process and print it as well, > does the main process stop too, or is it just the forked process? > > Btw, on my Linux machine your original example works the way you > expect. I get the output: > > 1 2 3 4 5 6 7 ... and so on, until I interrupt it. > > Both with v3.2.5 and current master branch. > > /Tommy > help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Quenio dos Santos
> On 21. Jul 2019, at 00:59, Quenio dos Santos <[hidden email]> wrote: Hi! > I haven't been able to compiler master on MacOS. I installed GCC and configured as follows, but it still seems to be using CLANG: You can use CC=/usr/loca.../gcc on configure and make ti pick GCC but either clang or gcc should be fine. > $ configure --prefix=/usr/local/Cellar/gcc/9.1.0 --with-gmp=/usr/local/Cellar/gcc/9.1.0 > ... > $ make > ... > cd packages/net && /Applications/Xcode.app/Contents/Developer/usr/bin/make > CC gnutls-wrapper.o > CCLD gnutls-wrapper can you use make V=1 to show me the link line? It seems it is not linking to GNUtls at all. Maybe have a look at config.log as well to see how gnutls support was found. But. At this stage you should already have a ./gst in the build/src directory. Can you see if it handles the process switching better? holger _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Hello Holger,
I've run into more problems as seen below. At this point, I'm ready to give up on getting the build working on my Mac. I'll keep using 3.2.5 for small scripts, and I'll start using Pharo for anything larger. Thanks for your help, Quenio On Mon, Jul 22, 2019 at 8:53 AM Holger Freyther <[hidden email]> wrote: > > > > On 21. Jul 2019, at 00:59, Quenio dos Santos <[hidden email]> > wrote: > > Hi! > > > > I haven't been able to compiler master on MacOS. I installed GCC and > configured as follows, but it still seems to be using CLANG: > > > You can use CC=/usr/loca.../gcc on configure and make ti pick GCC but > either clang or > gcc should be fine. > On MacOS, the gcc command actually runs CLANG. > > > $ configure --prefix=/usr/local/Cellar/gcc/9.1.0 > --with-gmp=/usr/local/Cellar/gcc/9.1.0 > > ... > > $ make > > ... > > cd packages/net && > /Applications/Xcode.app/Contents/Developer/usr/bin/make > > CC gnutls-wrapper.o > > CCLD gnutls-wrapper > > can you use make V=1 to show me the link line? It seems it is not linking > to GNUtls at all. > Maybe have a look at config.log as well to see how gnutls support was > found. > > But. At this stage you should already have a ./gst in the build/src > directory. Can you see > if it handles the process switching better? > > > Quenios-MacBook-Pro:smalltalk-playground quenio$ ~/Projects/gnu-smalltalk/smalltalk/gst --kernel-directory /usr/local/Cellar/gnu-smalltalk/3.2.5_8/share/smalltalk/kernel/ counter.im "Global garbage collection... done, heap grown" "Global garbage collection... done, heap grown" Segmentation fault: 11 > > holger _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
> On 22. Jul 2019, at 20:52, Quenio dos Santos <[hidden email]> wrote: > > Hello Holger, > > I've run into more problems as seen below. > > At this point, I'm ready to give up on getting the build working on my Mac. I have Macos too and we can share notes. > can you use make V=1 to show me the link line? It seems it is not linking to GNUtls at all. > Maybe have a look at config.log as well to see how gnutls support was found. > > But. At this stage you should already have a ./gst in the build/src directory. Can you see > if it handles the process switching better? > > > > I'm getting a segmentation fault when using the built gst: > > Quenios-MacBook-Pro:smalltalk-playground quenio$ ~/Projects/gnu-smalltalk/smalltalk/gst --kernel-directory /usr/local/Cellar/gnu-smalltalk/3.2.5_8/share/smalltalk/kernel/ counter.im > "Global garbage collection... done, heap grown" > "Global garbage collection... done, heap grown" > Segmentation fault: 11 Was there a reason to provide an image and use the 3.2.5 kernel instead of master? holger _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Hello Holger,
Sorry for the delay on replying. I got really busy the last couple of days. I was able to finally get the counter.st running continuously on my Mac with the master branch: $ ~/Projects/gnu-smalltalk/smalltalk/gst --kernel-directory ~/Projects/gnu-smalltalk/smalltalk/kernel counter.st 1 2 3 .... 225 226 ... It looks like master has the fix for MacOS. Thanks for your help, Quenio On Tue, Jul 23, 2019 at 12:51 PM Holger Freyther <[hidden email]> wrote: > > > > On 22. Jul 2019, at 20:52, Quenio dos Santos <[hidden email]> > wrote: > > > > Hello Holger, > > > > I've run into more problems as seen below. > > > > At this point, I'm ready to give up on getting the build working on my > Mac. > > I have Macos too and we can share notes. > > > > > can you use make V=1 to show me the link line? It seems it is not > linking to GNUtls at all. > > Maybe have a look at config.log as well to see how gnutls support was > found. > > > > But. At this stage you should already have a ./gst in the build/src > directory. Can you see > > if it handles the process switching better? > > > > > > > > I'm getting a segmentation fault when using the built gst: > > > > Quenios-MacBook-Pro:smalltalk-playground quenio$ > ~/Projects/gnu-smalltalk/smalltalk/gst --kernel-directory > /usr/local/Cellar/gnu-smalltalk/3.2.5_8/share/smalltalk/kernel/ counter.im > > "Global garbage collection... done, heap grown" > > "Global garbage collection... done, heap grown" > > Segmentation fault: 11 > > Was there a reason to provide an image and use the 3.2.5 kernel instead of > master? > > > holger > > > > help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
> On 26. Jul 2019, at 20:07, Quenio dos Santos <[hidden email]> wrote: > > Hello Holger, Hey! > Sorry for the delay on replying. I got really busy the last couple of days. > > I was able to finally get the counter.st running continuously on my Mac with the master branch: > > $ ~/Projects/gnu-smalltalk/smalltalk/gst --kernel-directory ~/Projects/gnu-smalltalk/smalltalk/kernel counter.st > 1 > 2 > 3 > .... > 225 > 226 > ... > > It looks like master has the fix for MacOS. fantastic. Can you help to get homebrew apply http://git.savannah.gnu.org/cgit/smalltalk.git/commit/?id=72ada189aba0283c551ead16635c1983968080b8? thank you holger _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Hi Holger,
I’ll hopefully look into it this weekend. I’ll get back to you when I have some progress. Thanks, Quenio On Fri, 26 Jul 2019 at 09:32 Holger Freyther <[hidden email]> wrote: > > > > On 26. Jul 2019, at 20:07, Quenio dos Santos <[hidden email]> > wrote: > > > > Hello Holger, > > Hey! > > > > > Sorry for the delay on replying. I got really busy the last couple of > days. > > > > I was able to finally get the counter.st running continuously on my Mac > with the master branch: > > > > $ ~/Projects/gnu-smalltalk/smalltalk/gst --kernel-directory > ~/Projects/gnu-smalltalk/smalltalk/kernel counter.st > > 1 > > 2 > > 3 > > .... > > 225 > > 226 > > ... > > > > It looks like master has the fix for MacOS. > > fantastic. Can you help to get homebrew apply > http://git.savannah.gnu.org/cgit/smalltalk.git/commit/?id=72ada189aba0283c551ead16635c1983968080b8 > ? > > thank you > > holger > > help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
In reply to this post by Holger Freyther
Your two blocks run okay on my Ubuntu 20.04 laptop running 3.2.5 GNU
Smalltalk. -- Sent from: http://forum.world.st/Gnu-f1290346.html |
Free forum by Nabble | Edit this page |