Обнаружение прерывания потока с помощью собственного ожидания вызова JNA (Windows)

Question

Я пытаюсь написать некоторый код, который выполняет ожидание через JNA (например, вызывая функцию Kernel32 WaitForSingleObject), но я также хотел бы, чтобы ожидание завершилось, если вызывается Thread.interrupt (); Я предполагаю, что Java использует что-то вроде объекта Event для реализации прерывания; Есть ли способ получить событие из Java, чтобы использовать его при вызове WaitForMultipleObjects? Или есть какой-то другой способ, которым я мог бы организовать мое ожидание, если нить прервана?

Answer 1

Java поддерживает его через NIO, и об этом мало кто знает, данный класс абстрактный, но это не проблема:

java.nio.channels.spi.AbstractInterruptibleChannel. У него есть 3 метода, представляющих интерес: begin() и end(), они являются окончательными, плюс тот, который вы должны реализовать: «защищенный абстрактный void implCloseChannel () throws IOException» Метод будет вызываться из потока, вызывающего interrupt (), поэтому будьте осторожны.

Использование очень просто: вызов начните перед вводом собственного кода и завершите () по возвращении. Обработка прерывания в implCloseChannel.

Удачного кодирования!

Answer 2

Потратив немного времени на дальнейшие исследования, сегодня утром я отправился на поиски экспедиции в исходном коде OpenJDK.Оказывается, начинать с нативной реализации было неправильно;для этого есть механизм на чистом Java.

Класс sun.misc.SharedSecrets имеет статический метод getJavaLangAccess (), который возвращает объект с методом blockOn (Thread, sun.nio.ch.Interruptible),Это может быть использовано для того, чтобы Thread.interrupt () вызывал метод, предоставленный одним из моих собственных объектов, после чего я могу создать свой собственный объект Event прерывания, с помощью которого я могу гарантировать, что ожидания прерываются по мере необходимости.

Выполнение этого вводит зависимости от реализации Sun библиотеки классов Java, но, вероятно, в меньшей степени, чем копание в собственном состоянии JVM, чтобы попытаться извлечь дескриптор события, который он использует внутри.