Re: aysnc functions v. callback_data

[Murray Cumming <murrayc murrayc com>]

On Fri, 2004-07-02 at 19:19 +0200, mhbouhmadi free fr wrote:
> 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.

That might be possible, but
1. This would mean that the callback would be called an extra time, and
that might cause strange behaviour in existing applications.
2. Not all of the callbacks receive a GnomeVFSResult parameter. For
instance, gnome_vfs_async_xfer().

> 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! 
> _______________________________________________
> gnome-vfs-list mailing list
> gnome-vfs-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com