GNOME Bugzilla – Bug 401083
Async API example
Last modified: 2011-01-16 23:36:25 UTC
While learning about and writing an example of using the asynchronous operations, I got stuck pretty quickly. The "example" so far is very simple, it tries to open and read a file passed as a program argument. The inspiration comes from the C test test-async.c found in gnome-vfs/tests. My goal is to have an example for transfers eventually. What I see is that here the SignalProxy_AsyncOpen::c_callback() function is never called after open() on an Async2::Handle is executed. So far I couldn't really follow further. I'll attach the code.
Created attachment 81281 [details] patch and example files In async-handle-2.hg I added Priority enum, defining the three priorities as in the C header. I've kept main.cc simple, even without calling close() before this is resolved.
By the way, I noticed that I have not done any gnome-vfsmm 2.17.x tarball release, so we have actually missed the API freeze for GNOME 2.18. Sorry. Is this very inconvenient for you?
I have committed the patch anyway, though I - removed the debug comments. - moved the Priority enum into Gnome::Vfs::Async2::Handle. Tell me if this doesn't make sense. - Added documentation for the enum items, from the C documentation. - In the example, removed the return type from print_vfs_error(). I have not investigated the problem yet. Is it possible that "delete handle" is being called too soon?
(In reply to comment #2) > By the way, I noticed that I have not done any gnome-vfsmm 2.17.x tarball > release, so we have actually missed the API freeze for GNOME 2.18. Sorry. Is > this very inconvenient for you? Well, certainly not inconvenient enough to ask for an API break now. Besides, I should've reminded you... (In reply to comment #3) > - moved the Priority enum into Gnome::Vfs::Async2::Handle. Tell me if this > doesn't make sense. Yes, the enum is meant to be used in Async2::Handle functions only, but I thought that since all (?) enums in *mm are kept in their root namespace, this one should follow as well. It becomes a habit to expect them there. Means less typing, too. > Is it possible that "delete handle" is being called too soon? Well... yes. I just tried. :/ I'll add some more functionality to the example then and rearrange the code in *.ccg a bit - the lines are way too long, it's really hard to read.
> the lines are way too long, it's really hard to read. I don't think it's normal to have an editor that's only 80 monospace characters wide, so I'd prefer not to have patches confused by whitespace changes. This also makes it difficult to include the examples inline in tutorial documentation.
Created attachment 81429 [details] [review] extended example The example is now mostly complete. I also have some API suggestions, but I'll open a new bug for that.
Created attachment 81430 [details] [review] extended example, with CL entry Sorry, forgot to add a ChangeLog entry.
Applied. Well done. So, there's no more know problem with async2?
There has been a g_warning() stating that transfer() leaks. I haven't investigated this yet. Also in the example I tried to use get_file_info(), but in my signal handler that does nothing a double delete occurred somewhere in gnome_vfs_*. I'll see what that is about.
So, I am reopening this bug because it sounds like this API change is not finished. Thanks for all your effort.
I'm closing this bug because giomm seems to be the answer to all our gnome-vfs problems.