Ernie Thanks for the reply and no problem .. I don't truly need to fork because all I want is a process that i can initiate a sandbox under using sandbox_init().
The "problem" is, I feel being able to spawn a child process without a separate codebase for initiating the sandbox is a much nicer solution, and then comes the problem of communicating the options for the sandbox between two processes that don't share any state. The parent also has the PID of the child, which makes a #terminate method very easy to implement. I've no idea about Service Management so maybe this information could be shared in some way, it just feels easier and cleaner to do so using fork() so the library would be one entity. If it helps give an idea, i've currently implemented this in MRI using fork(): http://github.com/robgleeson/Dia/tree/experimental Thanks, Rob On 18 Feb 2010, at 00:51, Ernest N. Prabhakar, Ph.D. wrote: > Hi Rob, > > On Feb 17, 2010, at 4:45 PM, robert gleeson wrote: >> Ernie -- >> >> It's not immediately obvious to me how I would spawn a process that is a >> copy of the parent using Service Management and right now >> "framework('servicemanagement')" doesn't seem to expose the functions >> mentioned in the documentation for service management .. I've tried >> traversing through Object.constants for a namespace they might reside under >> but no joy. > > I'm sorry, I didn't realize you wanted a true "fork"; SM just launches new > processes 'ab initio'. So, I'm afraid you're probably out of luck. > > For the record, what exactly is the use case where you want/need to inherit > the parent environment in the sub-process? > > -- Ernie P. > >> >> >> I'll try again tomorrow. >> >> Thanks, >> Rob >> >> On 17 Feb 2010, at 21:02, Ernest N. Prabhakar, Ph.D. wrote: >> >>> Hi Robert, >>> >>> On Feb 17, 2010, at 8:18 AM, robert gleeson wrote: >>>> Thanks Ernie -- >>>> >>>> I'm going to go through the documentation for the Service Management >>>> framework and see what I can come up with. I was hoping I wouldn't need to >>>> maintain two separate code bases for MacRuby and MRI but if i can launch >>>> processes without reverting to a hack it's always a good thing. >>> >>> Let us know what you come up with. It is possible we may be able to >>> (partially) emulate fork() using Service Management someday... >>> >>> -E >>> >>>> >>>> Thanks, >>>> Rob >>>> On 17 Feb 2010, at 15:45, Ernest N. Prabhakar, Ph.D. wrote: >>>> >>>>> The recommendation is to use launchd to spawn processes via Service >>>>> Management: >>>>> >>>>> http://developer.apple.com/mac/library/documentation/General/Reference/ServiceManagementFwRef/ServiceManagement_h/index.html >>>>> >>>>> But I don't think anybody has wrapped it yet... >>>>> >>>>> -- Ernie P. >>>>> >>>>> On Feb 17, 2010, at 5:42 AM, robert gleeson wrote: >>>>> >>>>>> Hi -- >>>>>> >>>>>> I'm aware fork() is not implemented in MacRuby yet, and it may never be >>>>>> from what I read but I'd just like to introduce a use case i've come >>>>>> across recently that might have you reconsider? >>>>>> >>>>>> I am writing ruby bindings for the features exposed in the "sandbox" >>>>>> header, and you really need to fork a process if you don't want your >>>>>> parent process to inherit the restrictions the sandbox imposes .. >>>>>> >>>>>> I came across the problem with CoreFoundation not allowing you to fork() >>>>>> without immediately executing exec() , and I presume this is one of the >>>>>> reasons fork() in MacRuby might not be implemented but is there any >>>>>> workaround to see fork() being implemented? >>>>>> >>>>>> Just thought I'd add that to the table. >>>>>> >>>>>> Thanks, >>>>>> Rob >>>>>> _______________________________________________ >>>>>> MacRuby-devel mailing list >>>>>> MacRuby-devel@lists.macosforge.org >>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>>>> >>>>> _______________________________________________ >>>>> MacRuby-devel mailing list >>>>> MacRuby-devel@lists.macosforge.org >>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>>> >>>> _______________________________________________ >>>> MacRuby-devel mailing list >>>> MacRuby-devel@lists.macosforge.org >>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >>> >>> _______________________________________________ >>> MacRuby-devel mailing list >>> MacRuby-devel@lists.macosforge.org >>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> >> _______________________________________________ >> MacRuby-devel mailing list >> MacRuby-devel@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > _______________________________________________ > MacRuby-devel mailing list > MacRuby-devel@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
