| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
I'll have to look a bit more into this. I thought that this LoadLibrary call there is not only pulling in that one symbol but that it serves as a "proxy" to enforce loading the library into memory s.t. the P/Invoke bindings work. Since your patch passes all tests (apart from the known failing one) I must have misunderstood something and will test this in our use-case to verify. Thank you already for your contribution, if this works out this will help a lot in simplifying the build process :) |
Sorry, something went wrong.
|
@filmor @amos402 I made a single Python.Runtime.dll to work with any Python 3.x interpreter in my fork (could have included 2.x, but its lifetime is ending) via extensive use of LoadLibrary and related methods. Which I intended to upstream once 2.7 is dropped (or, for example, if we had a separate 2.x branch in maintenance mode). |
Sorry, something went wrong.
|
@lostmsu What do you mean by "extensive use"? Isn't it enough to load libpython*.so once at startup? Could you point me to that code? |
Sorry, something went wrong.
|
@filmor well, the LoadLibrary is called once, but all the functions are obtained using GetProcAddress/dlsym. And also losttech@80aa07f All of that happens once at startup too. But there are many functions. There is probably a performance impact too, due to the use of delegates in place of PInvoke calls. |
Sorry, something went wrong.
|
@lostmsu What's your conclusion on keeping LoadLibrary? Does the code using delegates run reasonably or not? |
Sorry, something went wrong.
| @@ -297,16 +297,20 @@ internal static void Initialize(bool initSigs = false) | |||
| IntPtr dllLocal = IntPtr.Zero; | |||
| var loader = LibraryLoader.Get(OperatingSystem); | |||
There was a problem hiding this comment.
Seems like you should delete these lines too, and line 295 as well since you moved it below.
Sorry, something went wrong.
There was a problem hiding this comment.
This seems a quite reasonable patch, I think we should merge it.
I've had trouble in the past with this LoadLibrary/FreeLibrary screwing up the dlopen flags.
Sorry, something went wrong.
* Drop C module dependency when getting _PyObject_NextNotImplemented * Exception details for SetNoSiteFlag
Codecov Report
@@ Coverage Diff @@
## master #880 +/- ##
=======================================
Coverage 86.71% 86.71%
=======================================
Files 1 1
Lines 301 301
=======================================
Hits 261 261
Misses 40 40
Continue to review full report at Codecov.
|
Sorry, something went wrong.
|
I removed the dependency of zipimport. But still have no solution for SetNoSiteFlag, maybe we should add a docs for it(like please use -S when using static compile). |
Sorry, something went wrong.
| if (dllLocal == IntPtr.Zero) | ||
| { | ||
| dllLocal = loader.Load(_PythonDll); | ||
| throw new Exception($"Cannot load {_PythonDll}"); |
There was a problem hiding this comment.
Can you throw more informative exception? Win32Exception would automatically read last error on Windows, but I don't know what to do for *nix
Sorry, something went wrong.
There was a problem hiding this comment.
Generally it should throw inside from Load, the nullptr checking just for in case(if the loader implementation didn't throw an exception). I'm not going to insert any platform specific code here.
Sorry, something went wrong.
| private static IntPtr Get_PyObject_NextNotImplemented() | ||
| { | ||
| IntPtr globals = PyDict_New(); | ||
| if (PyDict_SetItemString(globals, "__builtins__", PyEval_GetBuiltins()) != 0) |
There was a problem hiding this comment.
Can PyEval_GetBuiltins() return an error?
Sorry, something went wrong.
There was a problem hiding this comment.
From the docs it doesn't look like it can (https://docs.python.org/3/c-api/reflection.html#c.PyEval_GetBuiltins).
Sorry, something went wrong.
There was a problem hiding this comment.
The globals dict is needed, but we don't seem to be using the __builtins__ in the string. Do we really need this line?
Sorry, something went wrong.
There was a problem hiding this comment.
If you don't setup a __builtins__ or set object explicit, object may not be found.
Sorry, something went wrong.
| XDecref(globals); | ||
| throw new PythonException(); |
There was a problem hiding this comment.
You might want to construct an instance of PythonException before doing XDecref, otherwise last error could potentially be overwritten by XDecref with something new.
Sorry, something went wrong.
| { | ||
| if (_PythonDll == "__Internal") | ||
| { | ||
| throw new NotSupportedException("SetNoSiteFlag didn't support on static compile"); |
There was a problem hiding this comment.
Why should this not be supported? The symbol is just in the running DLL, so loader.Load(_PythonDll) has to return essentially the result of dlopen(NULL, ...).
Sorry, something went wrong.
There was a problem hiding this comment.
Yes, it should be supported. Just a mistake according to my wrong tests. I will recover it back.
Sorry, something went wrong.
|
I believe issues #891, #946, and #967 all point to a fundamental problem with this PR. On certain Linux distributions (Debian for example), Python C extension libraries are deliberately not linked to libpython. Yet .NET Core's [DllImport] does not load libpython with RTLD_GLOBAL. So if this PR removes dllLocal = loader.Load(_PythonDll); from runtime.cs, where the salient line in LibraryLoader.cs is var res = dlopen(filename, RTLD_NOW | RTLD_GLOBAL);, won't this PR break Python.NET's "Embedding" mode on .NET Core? As Victor Stinner put it in Python issue issue 21536:
Unless we can get [DllImport] to set the RTLD_GLOBAL flag, I'm afraid we need the explicit loader.Load, at least for Linux .NET Core embedding. |
Sorry, something went wrong.
* Pick `SlotHelper` from pythonnet#958
|
@Jeff17Robbins This PR won't break "Embedding" mode on .NET Core, moreover it improve the compatibility since it didn't need call the dlopen. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
What does this implement/fix? Explain your changes.
There are some limitations to dynamic load a library on some systems(e. g. Android).
LoadLibrary just called for once for getting the _PyObject_NextNotImplemented,
we can use another ways to get this function.
Does this close any currently open issues?
No
Any other comments?
Checklist
Check all those that are applicable and complete.