У нас есть приложение java, поддерживаемое двоичным файлом fortran, который мы активно развиваем. Я в основном на стороне java, и я считаю своей задачей защитить людей, которые работают на fortran, от некоторых неприятных систем, которые могли бы в противном случае их беспокоить, например, параллелизма и не надавливания на них, чтобы выставить сложные API.Является ли callstack безопасной для пользователя структурой данных? Квазар + Фортран?
Одно из решений, которое я сделал в этих строках, состояло в том, чтобы передать обратный вызов стиля JNA из java в наши бинарные файлы fortran. Когда этот обратный вызов запускается на выполнение, наш CallStack будет выглядеть примерно так:
UIframework.click.java -- com.sun#1234
OurCode.UIHandlers.java -- our.code#2345
OurCode.doHeavyComputation.java -- our.code#4567
JNASurrogates.java -- com.sun.jna#456
JNASurrogates.proxy.f99 -- com.sun.proxies
HeavyComputation.f99 -- /code/algorithm.f99#1234
JNASurrogates.executeCallback.proxy.f99 -- com.sun.proxies
JNASurrogates.java -- com.sun.jna#1234
OurCode.computationComponents.java -- our.code#6789
//bottom of callstack
Мой вопрос один из потоков: как бы две нити доступ к одному и тому же в памяти FORtran DLL обрабатываться? Мой вопрос связан с точными подробностями о том, как обрабатываются дескрипторы в памяти: для того, чтобы компилятор fortran создавал код, который может быть вызван из JNA без использования другого счётчика программы, то у компилятора должен быть какой-то совместное понимание с JVM о том, где должен храниться столбец. Предоставляет ли X86 какой-то отдельный контейнер для программных счетчиков, который Pthreads, java.lang.Thread и другие библиотеки потоков, все рычаги, позволяющие безопасно изолировать вызовы?
Чтобы сделать вещи действительно интересно, я также обсуждаю с использованием Quasar - Для тех, кто незнаком, Quasar предлагает то, что он называет «волокно», которые являются «легкими нитями», реализуемым stackful сопрограмм, это означает, что Quasar выполняет прямые манипуляции с фреймами стека.
Проблема в том, что, хотя я концептуально рад выставить OurCode.computationComponents в качестве обратного вызова, некоторые бизнес-требования диктуют, что я не могу. Вместо того, чтобы просить наших прославленных fortran-программистов преобразовать свой существующий код в нечто с явными точками ввода и выхода (возврата), я бы скорее использовал сопрограмму, чтобы использовать наш существующий код.
Идея заключается в том, что сопрограмма бы выход при OurCode.computationComponents.java получая любые аргументы, которые были переданы, чтобы computationComponents от HeavyComputation.f99 как ReturnValue к вызывающей doHeavyComputation. Вызывающая затем сделать работу, что computationCompoennts обратного вызова обычно делает, передавая результат в от с resumeHeavyComputation, которая позволила бы получить обратно computationComponents и в конечном итоге вернуться к HeavyComputation.f99
Я могу, конечно, сделать все это с Блокировкой очередей и несколько потоков, но попытка ограничить себя использованием одного потока означает, что я получаю некоторое воздействие на Quasar, что приятно по нескольким причинам.
Может ли Quasar обрабатывать и безопасно восстанавливать стек так же сложно, как тот, который мы используем?