01:14 <byteit101[m]> should it always attempt to load a local binary gem, or only if you require it?

01:15 <byteit101[m]> ie: autoload system, manually load local?

01:34 <byteit101[m]> hmmm... libfixposix won't let us directly support rlimits like Process.spawn

01:36 <byteit101[m]> nor umask

01:54 <byteit101[m]> There's no way to do a whole-JVM synchronous block, right?

08:12 <headius> Sync on Object.class or some other core class is one way but if other libs do that you contend

08:13 <headius> There might be a newer blessed way I don't know about

08:15 <headius> As for the loading I'm not sure. You are thinking autoload when the library exists on the system so we have better spawn support out of the box, but if it is not present load from the binary gem... I suppose we could try to activate the gem automatically but it would be another library to load on boot

11:22 <byteit101[m]> the locking question was about a non-cloexec solution. Lock the jvm from doing any more io, list /proc/$$/fd/* and close those not listed, exec, unlock jvm

11:32 <headius> No way I know of to accomplish that unfortunately

11:34 <headius> /proc is a good thought but portability is obviously a concern

11:35 <headius> I don't know how much a concern it is that we don't close things since the JVM opens things CLOEXEC and so do we by default. The concern would be for applications that explicitly disable CLOEXEC and then want those others closed

11:36 <headius> I believe close_others predates CRuby doing CLOEXEC by default also

12:22 <byteit101[m]> Yea, that's why I was just going to lean on cloexec

12:23 <byteit101[m]> hence why I said "not really an issue" in the ticket

12:55 <headius> No worries