On 11/5/2018 9:57 AM, Matt Jadud wrote:
On Sun, Nov 4, 2018 at 5:30 PM George Neuner <gneun...@comcast.net <mailto: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.

We'll assume instead that you were simply mistaken <grin>

I am *not* using distributed places. I'm using *dynamic-place*, which clearly is why I'm running into limits.

Yes.  Big difference.

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.

If your issue really was caused by too many code files (yours + Racket's) eating up descriptors, then yes, switching to distributed places should alleviate the problem.

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.

Don't throw it away too quickly.

With a nod to process/thread scheduling: unless you muck with process/thread groups, by default Linux tries to gang schedule all the (ready) threads of a process to run simultaneously.

Rather than creating large numbers of processes each having 1 place, you might want to consider creating fewer processes that have several places each  [essentially a gang of thread pools].  If the places typically do significant amounts of work, leveraging the gang behavior of the scheduler *might* increase overall performance of the application as a whole.  [Particularly if the machine is not dedicated to your computing, and if the admins are not actively preventing you from exploiting this.  YMMV.]


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