Hi all, when trying to trace a bug in one of my externals i came across what could be an issue in the PD API.
The header m_pd.h exposes the function open_via_path which can be used in externals to search file in the PD search path. On success it opens the file and returns a file handle, which can in turn be used by the external code. This doesn't seem to be a problem on Unix-based systems. On Windows, under certain circumstances [1], PD and the external use separate copies of the CRT, meaning that passing the file handle and using POSIX-style file functions between dynamically linked binaries is not really possible. The file handle would not be valid in the external. This happens when at least one party is linked with the threaded static CRT, which is the default with PD and most externals.
Now, i'm wondering how this problem can have been hidden for so long. Are there no externals using open_via_path and running under Windows? This must be a problem for all script loader externals relying on the PD path, like my py/pyext external. Am i doing something wrong, or is there a known solution/workaround etc.?
Thanks and all the best, Thomas
[1] http://msdn.microsoft.com/en-us/library/ms235460(v=vs.80).aspx
-- Thomas Grill http://grrrr.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-03 15:19, Thomas Grill wrote:
Hi all, when trying to trace a bug in one of my externals i came across what could be an issue in the PD API.
The header m_pd.h exposes the function open_via_path which can be used in externals to search file in the PD search path. On success it opens the file and returns a file handle, which can in turn be used by the external code. This doesn't seem to be a problem on Unix-based systems. On Windows, under certain circumstances [1], PD and the external use separate copies of the CRT, meaning that passing the file handle and using POSIX-style file functions between dynamically linked binaries is not really possible. The file handle would not be valid in the external. This happens when at least one party is linked with the threaded static CRT, which is the default with PD and most externals.
Now, i'm wondering how this problem can have been hidden for so long. Are there no externals using open_via_path and running under Windows? This must be a problem for all script loader externals relying on the PD path, like my py/pyext external. Am i doing something wrong, or is there a known solution/workaround etc.?
Pd-0.43 introduced sys_close() in order to have the same CRT implementation open and close the file.
prior version of Pd lack this function and therefore there a number of file-handle leakage bugs were reported.
fgadsrm IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-03 15:40, IOhannes m zmoelnig wrote:
Pd-0.43 introduced sys_close() in order to have the same CRT implementation open and close the file.
prior version of Pd lack this function and therefore there a number of file-handle leakage bugs were reported.
sp the workaround is actually to use open_via_path() to get the full patch of the file you want to open, sys_close() the filehandle and then use the full-path to open the file yourself.
fgmasdr IOhannes
It's a workaround, yes.. but it's frequently necessary even within Pd where "open" wasn't really the desired function but one still needed to travers the search path to find a readable file. There ought to be a better way but I don't know what it is. An example is binbuf_read_via_canvas().
On another note, open_via_path isn't threadsafe - if one thread is changing the path it's unsafe for another to chase it. This happend in sfread~/ sfwrite~ and I'm still trying to think of a good fix.
cheers Miller
On Tue, Jul 03, 2012 at 03:49:00PM +0200, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-03 15:40, IOhannes m zmoelnig wrote:
Pd-0.43 introduced sys_close() in order to have the same CRT implementation open and close the file.
prior version of Pd lack this function and therefore there a number of file-handle leakage bugs were reported.
sp the workaround is actually to use open_via_path() to get the full patch of the file you want to open, sys_close() the filehandle and then use the full-path to open the file yourself.
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/y+EkACgkQkX2Xpv6ydvTkCwCfRvO9WVlNjg2/AZ0unQgs6qYs xLkAnAwTrGl7B/uqClNFrJP0o1VDzEpc =oSId -----END PGP SIGNATURE-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I see, thanks! That's perfect - sorry for not being up to date. gr~~~
Am 03.07.2012 um 15:49 schrieb IOhannes m zmoelnig:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-03 15:40, IOhannes m zmoelnig wrote:
Pd-0.43 introduced sys_close() in order to have the same CRT implementation open and close the file.
prior version of Pd lack this function and therefore there a number of file-handle leakage bugs were reported.
sp the workaround is actually to use open_via_path() to get the full patch of the file you want to open, sys_close() the filehandle and then use the full-path to open the file yourself.
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/y+EkACgkQkX2Xpv6ydvTkCwCfRvO9WVlNjg2/AZ0unQgs6qYs xLkAnAwTrGl7B/uqClNFrJP0o1VDzEpc =oSId -----END PGP SIGNATURE-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Thomas Grill http://grrrr.org +43 699 19715543
-
IOhannes m zmoelnig -
Miller Puckette -
Thomas Grill