Package ghidra.app.decompiler

# Class DecompilerDisposer

java.lang.Object
ghidra.app.decompiler.DecompilerDisposer

public class DecompilerDisposer extends Object

- ## Method Summary

  Modifier and Type
  Method
  Description
  `static void`
  `dispose(DecompInterface decompiler)`
  Calls dispose in the given decompiler from a background thread.
  `static void`
  `dispose(Process process, OutputStream ouputStream, InputStream inputStream)`
  Disposes the given Process and related streams from a background thread.

  ### Methods inherited from class java.lang.Object

  `clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait`

- ## Method Details

  - ### dispose

    public static void dispose(Process process, OutputStream ouputStream, InputStream inputStream)
    Disposes the given Process and related streams from a background thread. This is necessary due to a low-probability deadlock that occurs in the JVM.
    Parameters:
      `process` - The process to destroy.
      `ouputStream` - The output stream to close
      `inputStream` - The input stream to close

  - ### dispose

    public static void dispose(DecompInterface decompiler)
    Calls dispose in the given decompiler from a background thread.

    Note:
    A class to handle the rare case where the `DecompInterface`'s synchronized methods are blocking while a decompile operation has died and maintained the lock. In that scenario, calling dispose on this class will eventually try to enter a synchronized method that will remain blocked forever.

    I examined the uses of dispose() on the `DecompInterface` and determined that calling dispose() is a final operation, which means that you don't have to wait. Further, after calling dispose() on this class, you should no longer use it.