как это может быть запутанней?
- эй, процесс, останови загрузку
- остановил

там может есть какие тонкости, но это чат по электрону поискать лучше, я электрон не щупал никогда

Потому что нужно еще правильно вернуть 1 из 3 возможных результатов в тот метод который все начал, а он еще может и вовсе не получать ответов так как пользователь может и не останавливать, а нужно же как-то запускать загрузку по порядку ожидая когда закончиться предыдущая, там много нюансов выходит, я пока не могу сообразить как это лучше переделать что бы работало, мне пока проще понять в чем баг с ивентами стрима, а так нужно будет все переписывать в обоих процесах)

это 3 разных ивента.
stopped ? остановили
done ? следующую начинаем

что там ещё может быть

если там объекты можно передавать - можно вообще rpc сделать, наверное, передавая в ивенты ссылки на функции

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

почему эмиттер не должен ничего получать? а кто получать должен?

Получать должен первый эмитер, тот что начал загрузку, а второй эмитер начал остановку загрузки которую начал первый

ну так хэндлер другой создай

привет
подскажите чат, куда с вопросом по css сходить?

спасиб!

Где именно? В основном процессе и так уже 2шт один в другом) Еще и в процесе рендеринга создать внутри второй? Может получится какая-то гонка, я бы лучше продолжил делать по порядку, всякое может быть, вдруг один процесс подвиснет и все собьется

зачем один в другом?
один слушает одно действие, другое - другое
какая разница, кто пришлёт запрос на остановку загрузки?

А кто вообще тогда запустит саму загрузку? сама загрузка и ее результаты на разных процесах ведь, или я не так понял?

процесс 1 -> процесс 2: начни загрузку файла
2 -> 1: ок
1 -> 2: останови
2 -> 1: ок

Хз, это кажется почти тоже самое как есть сейчас, только больше ручной настройки с этими сообщения в обе стороны, и не факт что пропадет первоначальный баг, ведь как resolve не может в правильном порядке вернуть так и сообщения может не так отправить

сейчас там никаких сообщений нет, там в бесполезный промис обернуто создание хэндлера

оспаде, до сих пор?

Промис как раз возвращает результат на ивент, если заменить на то что в обратную сторону просто полетит новый ивент то будет тоже самое