- All Implemented Interfaces:
public class JCACommandThread extends ThreadJCA command pump, added for two reasons:
- JCA callbacks can't directly send JCA commands without danger of a deadlock, at least not with JNI and the "DirectRequestDispatcher".
- Instead of calling 'flushIO' after each command, this thread allows for a few requests to queue up, then periodically pumps them out with only a final 'flush'
- Initial version:CSS, 4-Jun-2012, Luofeng Li:added codes to support for the new archiver
- Kay Kasemir
Methods inherited from class java.lang.Thread
activeCount, checkAccess, clone, countStackFrames, currentThread, dumpStack, enumerate, getAllStackTraces, getContextClassLoader, getDefaultUncaughtExceptionHandler, getId, getName, getPriority, getStackTrace, getState, getThreadGroup, getUncaughtExceptionHandler, holdsLock, interrupt, interrupted, isAlive, isDaemon, isInterrupted, join, join, join, onSpinWait, resume, setContextClassLoader, setDaemon, setDefaultUncaughtExceptionHandler, setName, setPriority, setUncaughtExceptionHandler, sleep, sleep, stop, suspend, toString, yield
public void start()Version of
startthat may be called multiple times.
The thread must only be started after the first PV has been created. Otherwise, if flush is called without PVs, JNI JCA reports pthread errors.
NOP when already running
public void shutdown() throws InterruptedExceptionStop the thread and wait for it to finish
public void addCommand(Runnable command)Add a command to the queue. add some cap on the command queue? At least for value updates?