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.

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

\ No newline at end of file