асинхронный jsonrpc клиент-сервер

tornado

он же не умеет jsonrpc

https://github.com/joshmarshall/tornadorpc

и как оно ему поможет? Крутится в 1 потоке, исполняет там же. Хм. Хотя я только поверхностно глянул.

Вообще есть мнение, что Python JSON-RPC тоже осилит такое поведение. просто исполнение кидай в другой пул. асинхронный же тебе нужен вопрос/ответ

А ну так йопта! этот торнадо юзает то, что ТС в ссылке указал. Просто размазывает по своей логике.

Я бы сделал на asyncio, asynchttp и встроенной json-либой. Я пробовал, мне понравилось.

Go + net/rpc

пока пришёл к выводу, что нужно лезть в кишки pyjsonrpc, смотреть как он принимает и шлёт сообщения и потом вывернуть это в такое: на стороне сервера сделать очередь сообщений, клиент шлёт сообщение с сгенеренным id, сервер его принимает, кладёт в пул и обрабатывает сообщения из пула, как только какой-то таск закончился, возвращает его статус и id клиенту

Если у тебя сообщение обрабатывается долго из-за других сетевых запросов, а не из-за долгих вычислений, то ты делаешь неправильно.

jsonrps в принципе синхронный протокол, асинхронность это к amqp например. Давайте называть все своими именами, и искать обычный многопоточный сервер. Можно еще замутить на tornado или asyncio, но протокол от этого не станет асинхронным.

проблема в долгих вычислениях, а ждать я не могу

да, по сути мне нужен многопоточный сервер, умеющий jsonrpc

А вычисления на чистом питоне идут? Если так - то с потоками тоже плохо будет из-за GIL.

jsonrps в принципе синхронный протокол

чоэтовдруг? синхронным может быть обработка, а не протокол. Вполне видел рабочие асинхронные примеры на нем. Он ж расширяется легко.

ну, есть же multiprocessing

Да норм. Пул процессов все дела.

Обработка может быть асинхронной, но сам протокол где есть понятие «ответ», который не может быть до того как был отправлен запрос, не очень к такому распологает. Хотя конечно да, особенно если вспомнить букву А в слове АЯКС.