blob: 52df907e890fbd0287ae9d8a7b686e6b46f7d13e [file] [log] [blame]
<?xml version="1.0"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"" [
<refentry id="glib-programming">
<refentrytitle>Writing GLib Applications</refentrytitle>
<refmiscinfo>GLib Library</refmiscinfo>
<refname>Writing GLib Applications</refname>
General considerations when programming with GLib
<title>Writing GLib Applications</title>
The general policy of GLib is that all functions are invisibly threadsafe
with the exception of data structure manipulation functions, where, if
you have two threads manipulating the <emphasis>same</emphasis> data
structure, they must use a lock to synchronize their operation.
GLib creates a worker thread for its own purposes so GLib applications
will always have at least 2 threads.
See the sections on <link linkend="glib-Threads">threads</link> and
<link linkend="glib-Thread-Pools">threadpools</link> for GLib APIs that
support multithreaded applications.
When writing code that runs with elevated privileges, it is important
to follow some basic rules of secure programming. David Wheeler has an
excellent book on this topic,
<ulink url="">Secure Programming for Linux and Unix HOWTO</ulink>.
When it comes to GLib and its associated libraries, GLib and
GObject are generally fine to use in code that runs with elevated
privileges; they don't load modules (executable code in shared objects)
or run other programs 'behind your back'. GIO has to be used
carefully in privileged programs, see the <ulink url="">GIO documentation</ulink> for details.