Hi all,

First, thank you for the conversation around this.

On Sun, Nov 4, 2018 at 5:30 PM George Neuner <gneun...@comcast.net> wrote:

> One .zo per distributed place is just one descriptor per process.  Again
> insignificant because you have 4K per process.
> It's apparent that the code is leaking descriptors somewhere.  Forcing GC
> may mitigate the problem, but it would be better if you found the leak.
I've lied. I am *not* using distributed places. I'm using *dynamic-place*,
which clearly is why I'm running into limits.

Unless anyone has alternative ideas, I'm going to restructure my code to
use distributed places on the single machine, which will, I think, give me
multicore parallelism and eliminate the file descriptor limit I'm running
up against.

Many thanks, again. I locked in my head I was using distributed places, and
was blind to my own code. I've kept the test case I wrote, below, that let
me see clearly what I was doing, as opposed to getting caught up in all the
other things my code was engaged in. I'll leave it below for posterity's
sake, but it doesn't serve a particular role at this point.




I've written a small test case, and with Stefan's suggestion, dropped the
soft limit on descriptors to 100.

I can run my test case with 100 distributed places  when the soft limit is
1024 (and I end up with 708 descriptors in use when all of the distributed
places are idling), and it crashes immediately/very quickly when I drop
down to 100 descriptors.

[mjadud@phi subsetting]$ ulimit -n 100

[mjadud@phi subsetting]$ racket -um stress-queen.rkt

open-input-file: cannot open input file


  system error: Too many open files; errno=24

The files I used for testing are in this Gist:


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.

Reply via email to