Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

process hanging in embeded mode on exception #233

Open
behrica opened this issue Nov 20, 2022 · 2 comments
Open

process hanging in embeded mode on exception #233

behrica opened this issue Nov 20, 2022 · 2 comments

Comments

@behrica
Copy link
Contributor

behrica commented Nov 20, 2022

As a FUP of #221 which provided a new pathway to see the exception,
but does not prevent the "hanging" in an other pathway.

The simplest scenario is that we have a hanging python process by using this clojure code crash.clj

(ns train
  (:require [libpython-clj2.python :refer [py.- py.] :as py]
            [libpython-clj2.python.ffi :as ffi]))

(def locked (ffi/lock-gil))
(py/import-module "not existing")

and load it in embedded mode using manual-gil via:

export JDK_JAVA_OPTIONS="-Dlibpython_clj.manual_gil=true"
python -c 'from clojurebridge import cljbridge;cljbridge.load_clojure_file(clj_file="crash.clj")'

The exception thrown by python on the last line in crash.clj is swallowed by either clojurebridge or libpython-clj and the process hangs forever.

@behrica behrica changed the title haning in embeded mode on exception process hanging in embeded mode on exception Nov 20, 2022
@behrica
Copy link
Contributor Author

behrica commented Nov 20, 2022

I still have this open
behrica/clojurebridge#2

as I don't know where a potential fix needed to be.

@behrica
Copy link
Contributor Author

behrica commented Nov 21, 2022

Just to clarify.

There is an new API call which prevents the hanging seen above:

(py/with-manual-gil ...

But this API is by no mean mandatory, neither very prominently documented.
So users might still use the other API, as above, and get the experience of a hanging process.

I think we should throw an exception (and terminate the JVM) as well in the case above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant