Hi Rémi,
On 07/11/2011 03:11 AM, Rémi Denis-Courmont wrote:
On Friday 08 July 2011 21:23:34 ext Denis Kenzior, you wrote:
> Hi Oleg,
>
> <snip>
>
>> +static int gprs_provision(const char *mcc, const char *mnc,
>> + const char *spn,
>> + struct ofono_gprs_provision_data **settings,
>> + int *count)
>> +{
>> + int i;
>> + struct parser_data *data;
>> + *settings = NULL;
>> +
>> + DBG("Provisioning for MCC %s, MNC %s, SPN '%s'",
>> + mcc, mnc, spn);
>> +
>> + data = g_try_new0(struct parser_data, 1);
>> + if (data == NULL)
>> + return -ENOMEM;
>> +
>> + lookup_apn(mcc, mnc, NULL, data);
>
> What I wonder is what is the overhead of the XML parser right now (e.g.
> how long it takes on reasonable embedded hardware). If this takes a
> while, then it might be better to pre-parse the mobile-provider-info db
> during plugin initialization and not every time gprs_provision is
> called. Otherwise we run the risk of hanging the daemon while the
> provision settings are being looked up.
Provisioning should be a fairly rare occurence. Preparsing the table into
memory might be a waste of both CPU and memory in the common circumstances...
I do agree here, but it is the lesser evil than hanging the daemon for x
seconds. However, first I'd like to know what the parsing speed is...
If you suspect the parser is slow (I doubt it, but I have not
checked), then
it might be better to just do it in a separate thread in the rare cases that
you actually do need the data.
Separate thread will not help since the function has to return
synchronously. I doubt the overhead of storing this information will be
big, but if it is then we can play other tricks like pre-parsing the db
into a quick-look-up file format at start-up, etc.
Regards,
-Denis