Xref: utzoo comp.windows.x:29985 comp.windows.misc:1678 comp.windows.x.motif:1319
Path: utzoo!utgpu!watserv1!watmath!att!att!linac!uwm.edu!cs.utexas.edu!sun-barr!newstop!exodus!argv
From: argv@turnpike.Eng.Sun.COM (Dan Heller)
Newsgroups: comp.windows.x,ba.windows.x,comp.windows.misc,comp.windows.x.motif
Subject: Re: Resources & Forking
Message-ID: <3673@exodus.Eng.Sun.COM>
Date: 29 Nov 90 06:47:12 GMT
References: <1990Nov4.070135.11971@vicorp.com> <1990Nov28.191838.4990@arnor.uucp>
Sender: news@exodus.Eng.Sun.COM
Followup-To: comp.windows.x
Organization: O'Reilly && Associates
Lines: 32

In article <1990Nov28.191838.4990@arnor.uucp> gah@ibm.com (Gary Hoffman) writes:
> 1)  Is it possible to use X to read an X resource files without 
>     being connected to a server?
No.  You must be connected to the server in order for the Xlib routines
to access the database associated with it (you can have a resource file
unique to every server).

> 2)  If I open a display, then fork I presume both processes are
>     sharing a connection to the server.
Nope.  Just the parent.  The child's connection *must* be closed.
You can reopen a -new- connection to the server and rebuild widgets
or do whatever you want.  I submitted a program called "vines" to
comp.sources.x several months ago which demonstrates this.  Basically,
it just sits there and forks allowing each child to draw colored vines
all over your screen.  If you are using Motif to do things, your child
process will have to build those widgets specific to that process.
Thus, it is best to fork early in a program since forking causes the
entire dataspece to be copied.  Since running X programs can be large,
your forked process should try to do whatever it can quickly and get
out soon.

> If one process only 
>     wishes to read X resource files is there any problem with
>     not explicitly synchronizing the processes?  Or does any 
>     database operation require server contact?

None of this will work.
--
dan
----------------------------------------------------
O'Reilly && Associates   argv@sun.com / argv@ora.com
Opinions expressed reflect those of the author only.