Luke Graham
5/3/2005 4:52:00 AM
On 5/3/05, Luke Graham <spoooq@gmail.com> wrote:
> On 5/3/05, Brian Mitchell <binary42@gmail.com> wrote:
> > On 5/2/05, Luke Graham <spoooq@gmail.com> wrote:
> > > On 5/3/05, Brian Mitchell <binary42@gmail.com> wrote:
> > > > I have an upcoming project that will be on an MMU-less platform
> > > > (coldfire) running uClinux. I was possibly going to use ruby but it
> > > > seems that I cannot confirm if ruby supports vfork as an
> > > > implementation of forking or not. Is it possible at all?
> > >
> > > You should probably do this in a c extension, you could pass in the execve
> > > (or whatever) arg from ruby.
> > >
> >
> > Sorry I should have been more clear on this.
> >
> > My question was: Will ruby still run when fork is not available
> > (replacing fork with vfork or cutting out fork). The quick answer is
> > no. It will segfault if you add
> >
> > #define fork vfork
>
> Agreed, theres no way thats going to work. vfork != fork.
>
> > to ruby and run "fork". Will it still work if I avoid fork in ruby and
> > use, like you said, a C extension to vfork for me? (I don't have my
> > hardware to run tests on yet).
>
> I dont see why it wouldnt work. You have to abide by the rules of vfork
> though, which can be summarised as "nothing but exec or exit", so its
> kind of pointless.
Just to explain what I meant by this... For most (ruby) applications,
having vfork
is not better than having no fork. Having ruby running on mmu-less hw,
even with that caveat, is not useless :) If defining fork to vfork is enough to
get it working, then go with it.
--
spooq