Re: aysnc functions v. callback_data

[mhbouhmadi free fr]

One solution may be:
 - to have a new GnomeVFSResult enum value 'GNOME_VFS_ERROR_CANCELED'
 - to call the normal callback with GnomeVFSResult parameter equal to
GNOME_VFS_CANCELED.

Actually, the real problem is to have a clean and clearly identified protocol
about how callbacks are called in all circumstances and for each API function...

An example of my proposition is for gnome_vfs_async_load_directory: 
 - the callback is called many times (each time with the same amount of entries). 
 - When it is the last call the result parameter is equal to
GNOME_VFS_ERROR_EOF. So when we receive GNOME_VFS_ERROR_EOF, we may delete any
user data.

It may be sufficient if the callback is also called when the operation is
canceled with GNOME_VFS_ERROR_CANCELED, so that we can destroy user data.

This solution keeps the interface clean and consistent. I don't know gnome-vfs
internals to judge about how complex it is...

Hicham BOUHMADI.
-------------------------------------------------------------------
On Fri, 2004-07-02 at 12:12, Murray Cumming wrote:
> On Fri, 2004-07-02 at 09:59 +0200, Alexander Larsson wrote:
> > On Thu, 2004-07-01 at 16:54, Murray Cumming wrote:
> > > It looks like the async function needs extra destroy_callbacks
> > > 
> > > For instance,
> > > 
> > > in gnome_vfs_async_open(), we would normally release the callback_data
> > > when the callback is called, because we assume that the callback will
> > > only be called once. But if someone calls gnome_vfs_async_cancel() then
> > > the callback_data will never be released, because the callback will
> > > never be called.
> > > 
> > > So do we need new versions of these functions?
> > > 
> > >
http://cvs.gnome.org/viewcvs/gnome-vfs/libgnomevfs/gnome-vfs-async-ops.h?view=markup
> > 
> > I don't know why they weren't added when the functions were created, i
> > assume people thought "well, if the user cancelled the job they might as
> > well free the callback data (if they want that) at the same time". That
> > does require a bit more bookkeeping on the side of the app though  (you
> > need the mapping from wherever you store the outstanding handle to the
> > callback data for that handle).
> 
> I thought about this, but isn't it possible to have >1 async operation
> on the same handle at the same time?

Two reads on a file handle for instance? I don't think so. The async
handle is just a reference to the job in the job pool, and e.g.
gnome_vfs_async_read just sets the operation of the job.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a fiendish skateboarding senator from the Mississippi delta. She's a 
scantily clad kleptomaniac Valkyrie who don't take no shit from nobody. They 
fight crime!