Re: asynchronous libgnomecups implementation

[Jody Goldberg <jody gnome org>]

On Fri, Jun 18, 2004 at 02:00:01PM -0400, Colin Walters wrote:
> Hi,
> 
> Matthias Clasen and I have been working on adding an asynchronous API
> (vaguely modeled after GnomeVFS) to libgnomecups, and making the
> internals use this.

Sounds like a good idea.

> Right now it's fairly na??ve; it creates a new
> thread for every request.
Not terrible,  one would hope that the number of outstanding
requests would be small and bounded.

> I'm working on moving it to a model where it
> has a thread per server.
Sounds better, but I'm not sure it's worth the effort.

> +guint gnome_cups_request_execute_async             (ipp_t       *request,
> +						    const char *server,
> +						    const char  *path,
> +						    GnomeCupsAsyncRequestCallback callback,
> +						    gpointer cb_data,
> +						    GDestroyNotify destroy_notify);
> +
> +void gnome_cups_request_cancel (guint request_id);

Looks sane.

> +static gboolean
> +idle_signal_request_complete (GnomeCupsRequest *request)
> +{
> +	if (!request->cancelled && request->callback)
> +		request->callback (request->id, request->request,
> +				   request->path,
> +				   request->response,
> +				   request->error,
> +				   request->cb_data);
> +	else {
> +		ippDelete (request->request);
> +		ippDelete (request->response);
> +	}

Hmm, the memory management semantics here look inconsistent
Some of the callback args need to be released by the callback and
some are freed by the request.

> +gboolean
> +_gnome_cups_request_is_executing (void)
> +{
> +	gboolean ret;
> +
> +	g_static_mutex_lock (&request_mutex);
> +	ret = g_hash_table_size (request_map) > 0;
> +	g_static_mutex_unlock (&request_mutex);
> +	return ret;
> +}

1) I don't like this name it could be read as
    gnome_cups_request::is_executing
which doesn't match the interface

2) It would be simpler to say something like
    gnome_cups_outstanding_requests_count
and return the size of the queue too.