Re: Inheriting more file descriptors to NSTask

[Banlu Kemiyatorn]

Thanks,
It's okay, I'll just create another lgpl library subclassing NSTask and link to it.
Banlu

----- Original message -----
>
> On 7 Mar 2011, at 16:04, Banlu Kemiyatorn wrote:
>
> > On Mon, Mar 7, 2011 at 10:42 PM, Richard Frith-Macdonald
> > <address@hidden> wrote:
> > > Depending on what you are trying to do, you might redirect other
> > > decriptors to one of those, or you might try using named pipes to
> > > communicate between processes.
> >
> > I want to write to any predefined descriptor on target process and
> > think it would be nice if some extension GNUstep APIs allows this.
> > Could it fork and dup the child pipes to predefined descriptor number?
> > What would be a proper extension APIs for this?
>
> I don't like to be negative about things when people want to contribute
> code but the GNUstep policy is strongly to be Apple compatible ...
>
> For the core libraries themselves, that means we are actively (if
> slowly) trying to remove old extension code.  In gnustep-base that
> generally means moving extensions out of base itsself and into the base
> additions library.  So the obvious thing to do would be to implement any
> extension as something in the base additions library ... but the point
> of that library is to be built under OSX with the Apple
> compiler/runtime/Foundation, and enable code running on OSX to make use
> of our additions.  That means that code in the base additions library
> needs to work both when built with gnustep-base on *any* platform, and
> when built with Apple Foundation.  So an extension to NSTask there would
> also need to function as an extension to Apple's NSTask class ... which
> may be really difficult.
>
> In practice, this might mean moving almost the whole NSTask
> implementation into the additions library so that with OSX Foundation,
> you would actually replace Apple's implementation of NSTask with the
> GNUstep one. This would be a good thing (we already have an NSTask
> extension we need to get out of the base library), but may be more work
> than you want to get involved in.
>
>