Re: forking heap question

[Ralph Walden <rwalden tripos com>]

Don't forget, that there is actually a shared memory component.
That is, the widgets involve resources on the X server that are
common to the parent and child...  Manipulating them from
two different processes is a bad idea IMHO.


Ralph Walden


Edscott Wilson García wrote:
> 
> Paul Davis wrote:
> >
> > >Neither do I think it's possible. Yet, it is so. Maybe a failed malloc()
> >
> > no its not. virtual address spaces make it so. children have no access
> > to their parent's address space. global variables make no difference.
> >
> > >or free() makes the child access a gtk widget it's not supposed to, via
> > >some globally defined variable. This is the offending code executed by
> > >the child (the complete file is xtree_cpy.c from program xftree of the
> > >xfce desktop environment with CVS at sourceforge.net):
> > >
> > >The recursive call makes the parent fail quickly. The non recursive call
> > >also makes it
> > >fail, as long as the child executes it the subroutined enough number of
> > >times.
> >
> > have you checked that the recursion bottoms out? if the child uses all
> > of available RAM (physical and swap), the parent will make
> > a malloc call that returns NULL.
> 
> Yes. It does not bottom out. And the error occurs also in the
> non-recursive case, when the
> subroutine is performed within a simple loop. I have also noticed that
> with gtk either the parent or the child can take over the gtk widgets,
> depending on who accesses them first. So I believe some error (probably
> memory allocation stuff) is fooling gtk into thinking that the child has
> taken over the widgets, so when the parent tries to access them, it gets
> the "x io error", of course. This explanation would leave child and
> parent heaps totally independent, as should be. Maybe there is a way to
> tell gtk at the fork point whether child or parent will keep the widgets
> instead of leaving it up to gtk to decide?
> 
> --
> 
> saludos,
> 
> Edscott
> _______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-list

-- 

Ralph E. Walden
Tripos, Inc.
rwalden tripos com