В Unix-подобных операционных системах файловые дескрипторы (дескрипторы файлов), используемые для таких вещей, как каналы и сокеты, представляют собой небольшие целые числа.Обычно родительский процесс связывается со своим дочерним процессом, открывая канал, сокет или файл с определенным номером дескриптора файла.Это число будет либо согласовываться программистами родительской и дочерней программ, либо передаваться дочерней программе через командную строку или переменные среды.Затем дочерний элемент может получить доступ к унаследованному файловому дескриптору, используя тот же номер, что и родительский.
Существует ли соглашение о передаче номеров дескрипторов аналогичным образом в Windows?Насколько я могу судить, в соответствующих статьях MSDN говорится только о таких соглашениях для «стандартных» файловых дескрипторов (стандартный ввод, стандартный вывод, стандартная ошибка).Каким был бы надежный и идиоматичный способ сделать что-то вроде «передать канал в дескрипторе файла 3», как мы иногда это делаем в Unix?
В статье MSDN об наследовании говорится (выделено мое):
Унаследованный дескриптор ссылается на тот же объект в дочернем процессе, что и в родительском процессе.Он также имеет то же значение и права доступа.
Означает ли это, что я могу просто привести значение HANDLE к целому числу, преобразовать это целое число в строку и передатьэта строка в качестве аргумента командной строки для дочернего процесса, чтобы проанализировать и получить тот же дескриптор, и это надежно или привычно?Есть ли какой-нибудь другой механизм IPC, который вместо этого обычно использовали бы программисты Windows?
Основная мотивация для меня - избегать временных файлов и использовать каналы.Это обычно, когда все, что у вас есть, это стандартный ввод / вывод, но меньше, когда у вас несколько каналов.