Which version of Racket are you building? The parallel build uses Racket places (as opposed to threads), which is why it can usefully build in parallel. There have historically some bugs in the interaction of GC and places, but I haven't not seen reports of problems with the latest release.
The Racket build can also run in parallel using separate processes. If you configure with `--disable-places` but still provide `-j <n>` to `raco setup`, then setup will use processes instead of places. Building that way may avoid memory-management problems related to places while providing useful parallelism. At Tue, 22 Sep 2015 01:34:14 -0700 (PDT), Дмитрий Кашин wrote: > Dear all, > > I wanna notice that it was originally sent into us...@racket-lang.org mailing > list, but it was rejected by list's moderator because list had been moved to > Google Groups. So I resend it via Gmail. > > I did not understand how to send and to get letters here with my mail client, > so I have some problems with communication here. I'd be glad if somebody > explains me how to do it: I'm really newbie with Google Groups. > > ----- > > Hello everybody. > > Our company produces DPL systems using Racket Scheme language. Sometimes (but > very rare) we make some contributions to the Racket standard collections, and > we have a big problem: the rebuild process of Racket takes about 4 hours, and > it harms our continuous integration process. Espesially it harms us when we > want to set up a new build stand. I wanted to decrease this time using > multiple threads because I heard that Raco can work with them. > > While building the compiler itself I used "make -jN". I've been also trying > to > set PLT_SETUP_OPTIONS to "-j N" where N is a number of threads. > > But I've found that the build in this way can produce some inconsistent > result. Builds with 8 threads has crashed as bad as with 7 ones. With 6 > threads the build has finished with success in 20 minutes for 3 times, but > then 3 times failed with different SIGSEGV errors. > > Here are some of them: > 1. SIGSEGV MAPERR si_code 1 fault on addr 0x7fd774b54018 > 2. SIGSEGV SI_KERNEL SI_ERRNO 0 fault on addr (nil) > > They could happen at random time at compilation of random collection. Address > could be nil or some different. The second error was seen by me more often > than the first one. > > I suppose that it's the problem of GC because it uses SIGSEGV for some > purposes. Maybe I should disable GC? But is it possible and how? > I need a recommendation how to solve this problem. Does somebody build Racket > with multiple threads? Is there a correct way to do it? How could I achieve a > consistent build? > > UPD: > I've set PLTDISABLEGC="1" trying to disable GC. And I've got the same: > "SIGSEGV MAPERR si_code 1 fault on addr 0x8". > So I think it could be not a garbage collector's problem. > > BTW, I want to understand how raco does parallel building process into > threads. I know that racket does not have native threads, but has only green > ones. But in htop I saw numerous threads (I suppose it was threads because > they shared the save virtual memory). How could it be? Do raco use native > threads because it's written not in Racket but in C/C++? > > UPD#2: > I returned to a consistent building of racket with 1 thread. I don't see a > way > how to have guarantees that the build is fine with such a strange raco's > behavior. Need a discussion. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
