Re: How do we use the GtkPlug and GtkSocket using threads without a fork() call?

["Robert E. Hartley" <rhartley ics com>]

I think in the source it checks to see if it has same PID when connecting the
two together, and spits out a warning if so.

I am wondering about using other widget sets as an interim measure for when
converting to a new one, so I wanted to have the ability to encapsulate a
widget from one set into another, and use it in an application with different
threads handling the different event loops.

So far it works wonderfully after a fork(), but there seems to be a problem
with using the same X connection when using threads.  The pipe or socket used
does not have the events replicated between the different threads, whereas the
fork() forces them to be duplicated, in effect re-opening everything up and
automatically creating a new connection for the spawned process.

A work around would be to use the fork() call, and Orbit for IPC stuff to
handle the shared objects/variables.

Problem is that I would like it to be short and sweet, so I was wondering if
you guys also had the GtkPlug/GtkSocket combos running in different threads in
addition to different different processes.

I am convinced this thing can be done, I am mainly curious to see how
difficult and time consuming it would be.

If you already have this sort of problem figured out, it would make it easier
to stop using the old primitive toolkit and modernize things quicker,

Thanks for getting back to me so quick, and for any help you can lend,

Robert

Owen Taylor wrote:

> > How do we use the GtkPlug and GtkSocket using threads without a fork()
> call?

> GtkPlug/GtkSocket are for interapplication embedding. If you are threading,
> I would expect you to simply use normal GTK+ containers.