S60 Open C
Introduction to Glib

Introduction to Glib

Table of Contents

Differences between OSS and Symbian Glib
Memory allocation
Spawn APIs
Libgmodule APIs

 


Differences between OSS and Symbian Glib

The three areas of difference between the way Glib is implemented in Symbian OS and in OSS are as follows:

 


Memory allocation

The Symbian Glib implementation does not follow the default OSS behavior. The default OSS behavior is such that in the event of a memory allocation failure the application, using g_malloc() and not g_try_malloc(), will call abort() and thus terminate the application.

The Symbian implementation, on the other hand will return NULL and not terminate the application in the event of a memory allocation failure. Thus, it is the application’s responsibility to check if the memory allocation failed due to the needed tasksl.

Generally, all the application code written using glib does not perform memory allocation failure checks. Hence, for Symbian Glib it is the application programmer's responsibility to check for memory allocation failures.

 


Spawn APIs

Glib has a set of APIs for process spawning. Since Symbian OS does not support the fork() and exec() APIs, the g_spawn*APIs have limitations in their functionality. The limitations are explained per API in detail below.

g_spawn_async_with_pipes: The signature of this API is

gboolean g_spawn_async_with_pipes (
    const gchar *working_directoy,
    gchar **argv,
    gchar **envp,
    GSpawnFlags flags, 			
    GSpawnChildSetupFunc child_setup, 			
    gpointer user_data, 			
    GPid *child_pid, 			
    gint  *standard_input, 			
    gint *standard_output, 			
    gint *standard_error, 			
    GError **error); 

This API executes the program asynchronously: that is, the caller does not block for the spawned process to complete. The setting of the following parameters does not have any effect in Symbian Glib:

  • working_directory
  • envp

If a value other than NULL is passed for standard_input, standard_ouput, or standard_error, the value at the location is set to -1.

g_spawn_async: The signature of the API is

gboolean g_spawn_async (
    const gchar *working_directory, 	 	  
    gchar **argv, 		  
    gchar **envp, 		  
    GSpawnFlags flags, 		  
    GSpawnChildSetupFunc child_setup, 		  
    gpointer user_data, 		  
    GPid *child_pid, 		  
    GError **error); 

This API calls g_spawn_async_with_pipes without any pipes. The setting of the following parameters does not have any effect in Symbian Glib:

  • working_directory
  • envp

g_spawn_sync: The signature of the API is

gboolean g_spawn_sync(
    const gchar *working_directory, 	 	
    gchar **argv, 		
    gchar **envp, 		
    GSpawnFlags flags, 		
    GSpawnChildSetupFunc child_setup, 		
    gpointer user_data, 		
    gchar **standard_output, 		
    gchar **standard_error, 		
    gint *exit_status, 		
    GError **error); 

This API executes the program synchronously: that is, the calling process waits for the spawned process to complete before returning. The setting of the following parameters does not have any effect on Symbian Glib:

  • working_directory
  • envp

If a value other than NULL is passed for standard_output or standard_error, the value at the location is set to -1.

g_spawn_command_line_sync: The signature of the API is

gboolean g_spawn_command_line_sync(
    const gchar *command_line, 
    gchar **standard_output, 
    gchar **standard_error, 
    gint *exit_status, 
    GError **error);  

This API is a simple version of g_spawn_sync in which there are fewer number of parameters involved, and it takes a command line instead.

If a value other than NULL is passed for standard_output or standard_error, the value at the location is set to -1.

In many spawn APIs a variable of type GSpawnFlags is passed. The following flags have no effect:

  • G_SPAWN_LEAVE_DESCRIPTORS_OPEN
  • G_SPAWN_STDOUT_TO_DEV_NULL
  • G_SPAWN_STDERR_TO_DEV_NULL
  • G_SPAWN_CHILD_INHERITS_STDIN

 


Libgmodule APIs

Libgmodule has APIs that provide a portable method for dynamically loading 'plug-ins' or, in other words, DLLs. There are some deviations in the libgmodule APIs on Symbian OS as compared to the OSS behavior. The APIs with their limitations are explained in detail below.

g_module_open: The signature of the API is

GModule *g_module_open (const gchar *file_name, GModuleFlags flags); 

This API is used to open a module. The default OSS behavior when file_name is passed as NULL such that it obtains a GModule representing the main program. In Symbian Glib, NULL is returned instead. Of all the GModuleFlags only G_MODULE_BIND_LOCAL is honored. If the user passes any other flags, the module is still opened using the flag G_MODULE_BIND_LOCAL.

g_module_symbol: The signature of the API is

gboolean g_module_symbol (GModule *module, const gchar *symbol_name, gpointer *symbol); 

This API gets the symbol from the GModule opened using g_module_open. In OSS, symbol_name is the name of the symbol that needs to be queried from the GModule. In Symbian OS, the ordinal number (passed as a string) of the symbol name must be passed and not the symbol name.

See also Introduction to libgmodule for more details about libgmodule.

Give feedback of this section


©Nokia 2007

Back to top


This material, including documentation and any related computer programs, is protected by copyright controlled by Nokia. All rights are reserved. Copying, including reproducing, storing, adapting or translating, any or all of this material requires the prior written consent of Nokia. This material also contains confidential information, which may not be disclosed to others without the prior written consent of Nokia.

Nokia is a registered trademark of Nokia Corporation. S60 and logo is a trademark of Nokia Corporation. Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. Other company and product names mentioned herein may be trademarks or tradenames of their respective owners.