Обработка потенциально больших данных STDIN более одного раза

Я хотел бы предоставить метод доступа к классу, который предоставляет NSInputStream для STDIN, который может содержать несколько сотен мегабайт (или гигабайт, что маловероятно) данных.

Когда вызывающий объект получает этот NSInputStream, он должен иметь возможность читать из него, не беспокоясь об исчерпании содержащихся в нем данных. Другими словами, другой блок кода может запросить NSInputStream и ожидать возможности чтения из него.

Без предварительного копирования всех данных в объект NSData, который (я полагаю) вызовет нехватку памяти, каковы мои варианты обработки этого? Возвращенный NSInputStream не обязательно должен быть одним и тем же экземпляром, он просто должен предоставить те же данные.

Лучшее, что я могу придумать прямо сейчас, это скопировать STDIN во временный файл, а затем вернуть экземпляры NSInputStream, используя этот файл. Это почти единственный способ справиться с этим? Есть ли что-то, с чем я должен быть осторожен, если я пойду по маршруту временного файла?

РЕДАКТИРОВАТЬ | Я должен упомянуть, что это не на самом деле STDIN, это многопоточное приложение FastCGI, и это поток FCGX_Request.in, который поступил из STDIN.


person d11wtq    schedule 29.05.2010    source источник


Ответы (1)


При чтении данных из канала или сокета у вас есть три варианта:

  • Обработайте и забудьте.
  • Добавьте его к полной записи в памяти и обработайте до или после этого.
  • Добавьте его в полный файл и обработайте до или после этого.

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

Единственный другой способ снова получить данные — отправить их вам снова.

person Peter Hosey    schedule 29.05.2010
comment
Великолепно, спасибо, мне нужно обработать данные самостоятельно, а затем снова сделать их доступными для потребителя, поэтому я думаю, что я просто пойду на свой первый инстинкт и запишу их во временный файл. - person d11wtq; 29.05.2010