Есть ли способ сказать, что значение дескриптора файла было повторно использовано? - PullRequest
3 голосов
/ 22 декабря 2011

У меня есть API, который вызывается с дескриптором файла в качестве аргумента, и он внутренне хранит некоторое состояние, связанное с дескриптором файла.Затем при последующих вызовах с тем же значением дескриптора файла можно просмотреть ранее созданное состояние.

В основном это работает, за исключением случая, когда вызывающий код вызывает мой API с дескриптором файла, а затем закрывает дескриптор файла.Затем выделяет новый файловый дескриптор (через socket () или accept () или т. д.), который в итоге получает то же целочисленное значение, что и закрытое, и передает этот новый файловый дескриптор моему API.В этот момент мой API делает не то, потому что он ошибочно связывает состояние старого сокета с новым файловым дескриптором.

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

Поэтому мне интересно, есть ли какой-нибудь умный способ определить, связан ли дескриптор файла во время T с теми же базовыми структурами, с которыми он был связан во время (Tx).Если бы я мог это сделать, мой API был бы достаточно умен, чтобы определить, когда целочисленное значение дескриптора файла использовалось повторно, и сделать все правильно.

FWIW этот код предназначен для запуска в первую очередь под MacOS / X и Linux, но чем более портативное решение, тем лучше.

1 Ответ

2 голосов
/ 23 декабря 2011

Я так не считаю.

Вам лучше предоставить обертки для открытия / закрытия, которые возвращают непрозрачный тип обратно вызывающим.(Вы также можете предоставить функцию для извлечения базового файлового дескриптора из этого непрозрачного типа, если это необходимо.)

Если вы не хотите переносить открытие / закрытие, вы все равно можете использовать непрозрачную структуру для своих API.(просто создайте пару функций для создания (с параметром дескриптора файла) и освободите эту структуру), но действительно, ваши пользователи должны будут помнить, чтобы освободить, или приложение утечет.(Но разработчик C должен знать, как это сделать - malloc / free существует уже некоторое время.)

В зависимости от того, что именно предоставляет ваша библиотека, вероятно, есть лучшие альтернативы, но этоэто то, что, как я полагаю, обычно делается для API C.

Примечание: если вы ожидаете, что ваша библиотека и код пользователя будут выполнять чтение и запись в эти сокеты ... будьте осторожны, это действительно сложно.

...