Re: [pdf-devel] http filesystem create/destroy functions needed

[jemarch]

   In the init_fn I will need save a reference to libcurl for use in a
   variety of functions during normal runtime.  My instinct is to have
   a pdf-fsys-http.c scoped static structure to store this, and a
   couple other items in.  This will make it accessible to all my
   functions without any overhead.

   Will multiple instances of the http filesystem be necessary? I have not
   noticed anything of this sort in the requirements...


As Aleks already pointed out, the right thing to do depends on the
nature of that libcurl_handle.  I can read in the libcurl FAQ:

   "Never share libcurl handles between multiple threads. You should
   only use one handle in one single thread at any given time. You can
   still share certain data between multiple threads by using the
   share interface."

So we need to maintain a handle per instance of the http filesystem
(in principle nothing prevents the user to operate more than one http
filesystem).

I just pushed a patch to add an additional parameter to the following
filesystem implementation callbacks:

   create_folder_fn
   get_folder_contents_fn
   get_parent_fn
   remove_folder_fn
   get_item_props_fn
   get_free_space_fn
   item_p_fn
   item_readable_p_fn
   item_writable_p_fn
   file_open_fn
   file_open_tmp_fn

Note that the file interface callbacks can access to the 'data' field
of the filesystem associated with the open file, so they don't need
the extra parameter.

That should be enough to use libcurl in a thread-safe way.  Please
confirm if it is the case.

-- 
Jose E. Marchesi  <address@hidden>
                  http://www.jemarch.net
GNU Project       http://www.gnu.org