-
Notifications
You must be signed in to change notification settings - Fork 143
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
Internal thread is not a daemon thread #125
Comments
I understand that it's appealing to not have background threads block JVM exit, but I'm not sure this is a correct use of daemon threads. My understanding is that they are intended to do low-priority background tasks like garbage collection. See this article for some information. This article talks about a potential pitfall of using daemon threads. |
Hi dougmeredith,
your second reference is in my eyes a misunderstanding of the API and in
particular of daemon threads. So I won't talk about this.
Your first reference explains that a daemon thread 'serves a user thread'.
This is actually the case with nrjavaserial. The thread in nrjavaserial
serves user threads processing the incoming data from a serial port.
If all user threads have terminated, then there is and will never be again
a user thread that can cooperate with the nrjavaserial thread. So in this
case, the VM could simply go down, vs. the current situation, where the
user thread has to call System.exit(); explicitly.
The good case with nrjavaserial is that when the user properly closes the
connection the thread is also stopped. So a hanging application is the
consequence of a missing close on a serial stream, and thus an application
error.
Nevertheless, because of the above argument, I think it would be a step
forward for nrjavaserial if the internal thread would be a daemon.
Best wishes,
Michael.
Am Di., 22. Jan. 2019, 20:07 hat dougmeredith <notifications@github.com>
geschrieben:
… I understand that it's appealing to not have background threads block JVM
exit, but I'm not sure this is a correct use of daemon threads. My
understanding is that they are intended to do low-priority background tasks
like garbage collection.
See this article <https://www.baeldung.com/java-daemon-thread> for some
information. This article
<https://meteatamel.wordpress.com/2012/05/22/when-a-daemon-thread-is-not-so-daemon/>
talks about a potential pitfall of using daemon threads.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#125 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABKqPeBOVZpIGA0fQDDiC8g7oSJQF6DRks5vF2FkgaJpZM4VqhkZ>
.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The thread started by nrjavaserial is not declared as a daemon thread.
This results in a hanging application if the #main() operation simply returns, since non-daemon threads prevent the Java-VM from termination.
Better is to declare these threads as daemon threads.
A workaround is to call System.exit().
The thread in question is started in RXTXPort.java
The text was updated successfully, but these errors were encountered: