Differences between OSS and Symbian GLib

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

  • Memory allocation

  • Spawn APIs

  • Libgmodule APIs

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 tasks.

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 platform 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 platform 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 platform, 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.