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 <[email protected]> http://www.jemarch.net GNU Project http://www.gnu.org
