Re: [cdt-patch] Patches to process management libraries and classes

["Alain Magloire" <alain@xxxxxxx>]

> I'm running the IBM 1.3.1 VM on a RH 7.3 host.
> 

The IBM VM?  interesting.
We've found it to be a little slow compare to Sun's VM.

> After digging around a little, I found that the exec0 function =
> exec_unix.c was releasing a pointer passed in and, presumably, managed =
> by the caller.  I've attached a patch, unix_exec.c.patch, that fixes =
> that problem. =20

Patch apply.  Thanks

> 
> I also took the liberty of changing the make file so the user could =
> specify JDK_INCLUDES and JDK_OS_INCLUDES as environment variables.  If =
> the the environment variables are not present, the Makefile sets them to =
> the same values as the prior version of the file and produces a warning =
> in case that's not what the user intended.  I also added a rebuild =
> target and removed the commented-out line in the clean target that did =
> not delete the spawner object files and shared library.  The attached =
> patch file, Makefile.patch updating the Makefile with these changes.
> 

Done on the linux fragment(considering that GNU make will always be the
default make on this platform).

> The third patch file, org.eclipse.cdt.core.patch, addresses a problem I =
> was seeing with Spawner/Reaper synchronization in my environment.  The =
> command would run, produce data on stdout, but the Reaper's output =
> buffer was empty.  I addressed this problem by separating the Reaper =
> class from the Spawner class and changed the constructor to make the =
> explicit the parent/child relationship between these classes.  So  =
> instead of using the Spawner.this as a synchronization object, the =
> Reaper's constructor accepts a reference its parent object and uses that =
> reference for synchronization.  I also create the in/out/err streams =
> before releasing the lock on the object and the accessors also lock the =
> object before returning the references to the in/out/err streams.
> 

Your patch is corrupted, missing lines etc ..
Could you resend it, this time a unified or context diff

diff -u
or 
diff -c

> I would appreciate if the maintainer of this code could review my =
> changes incorporate them into the project's repository.
> 

Thanks.