Hi,
BTW, I guess some
MT lock should be moved from s_file*() to hb_file*(). s_fileMtx and
s_openFiles are static variable, and it is not possible to implement for
example MT safe file close function for additional file protocols. Perhaps
additional functions to insert/delete items into/from s_openFiles list is
the best solution.
It's not necessary. Look at the code.
Now s_fileMtx is used for two different things.
1. to protect standard HB_FILE handlers in s_openFiles list so they are
MT safe.
2. to protect s_pFileTypes/s_iFileTypes in hb_fileRegister() function
to make runtime file type registration MT safe though I do not know
if it's really necessary because in most of cases new file IO API
will be registered by startup code. Though maybe it will be usable
if we add unregister function.
Any other alternative IO API may use or not internal mutexes. It depends
on their internal implementation, i.e. you can very easy implement pure
redirector to hb_fs*() functions without any additional functionality with
very simple HB_FILE structure which is not stored in any list, i.e.
look at code below. I've just written it as example without any tests
so it's possible it has some typos but it should show the main idea.
It does not use any mutexes but it's fully MT safe though on POSIX
systems it restores known problem with synchronization of aliased areas.
Oh, yes.
Both general hb_file*() functions and a particular file protocol
functions s_file*() is implemented in the same module, and it uses the
same s_fileMtx for different purposes. This lead me to the wrong idea,
that all file protocols should store open file structures in the same
s_openFiles list. Now it is clear.
Regards,
Mindaugas
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
