- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
#include <stdio.h>
#include <stdlib.h>
int main()
{
FILE *fp;
char hc1,hc2,mc1,mc2;
int hi1,hi2,mi1,mi2,hour,minute;
system("echo %time% >time.txt");
fp=fopen("time.txt","r");
if(fp==NULL)
exit(1) ;
hc1=fgetc(fp);
hc2=fgetc(fp);
fgetc(fp);
mc1=fgetc(fp);
mc2=fgetc(fp);
fclose(fp);
remove("time.txt");
hi1=hc1;
hi2=hc2;
mi1=mc1;
mi2=mc2;
hi1-=48;
hi2-=48;
mi1-=48;
mi2-=48;
hour=hi1*10+hi2;
minute=mi1*10+mi2;
printf("Current time is %d:%d\n",hour,minute);
return 0;
}
Как узнать текущее время особо извращенным образом. http://stackoverflow.com/questions/5141960/get-the-current-time-in-c
Follow us!
и к слову, в одной книге по виндам, внешний файл был перечислен как официальный способ IPC.
или как сверху, или:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682499%28v=vs.85%29.aspx
Э-э-э-э...
нет пайпов который наследуются дочерним процессом.
пример в msdn линке хорошо описывает как и чем убоги винды.
можно дочернему процессу просто передать дескриптор пайпа и в этот пайп писать или из этого пайпа читать.
можно два/более дочерних процессов в цепочку посадать.
можно два дочерних процесса с друг другом завявать: один читает то что другой пишет и наоборот.
и это все в одну страницу кода. чаще меньше. и только изредка больше.
самое красивое часть что пайп это нормальный файл дескриптор. как и сокет и фифо. что значит что дочерний процесс в общем случае и не знает откуда читает, куда пишет.
В create process отлично передаются хендлы, вроде бы даже любые (файлы, сокеты и т.п.). И свой stdout, емнип, вполне отдаётся. Лишь бы вызываемое приложение было консольным.
Когда последний раз это пытался делать (времена винды 2000) там все было обложено граблями.
Я пытался достаточно тривиальную вещь с линуха перетащить. Где-то на пятой странице кода остановился. Были какие-то грабли с контекстами безопастности и надо было еще где-то пять страниць писать/копипастить с MSDNа. Я просто забил.
А вообще - NT и *nix довольно далеки друг от друга, у них есть свои достоинства, недостатки и годные фичи. И если идти со своим уставом в чужой монастырь, и пытаться сделать прямой порт изначально некроссплатформенной проги - почти всегда получается унылое говно.
очевидно. но иногда просто хочется попробовать прикрутить концепции и парадигмы, которые весьма продуктивны на других системах.
на виндах создание процесса всегда была очень медленной операцией. (говорят что это VMSная традиция, и там были теже грабли.)
я читал что только начиная с висты есть легко-весные процессы, которые запускаются быстрее.
И да: bInheritHandles [in]
If this parameter TRUE, each inheritable handle in the calling process is inherited by the new process. If the parameter is FALSE, the handles are not inherited. Note that inherited handles have the same value and access rights as the original handles.
Имхо, намного разумней, чем наследовать всё подряд, как в никсах, а потом ебаться с CLOEXEC или тупо закрывать все дескрипторы циклом...
в прошлом так же была проблема что на виндах запуск приложения занимал как минимум 25мс (время от CreateProcess() до входа в main()). больше 40 раз в секунду что-то запустить в принципе было не возможно. когда это тестировал, создавалось впечатление что там какой-то слип где-то был встроен, потому что время было всегда в районе 25мс.
Будем честны - никсовые приложения, которые юзают унаследованные хендлы больше второго, тоже специально под эти цели заточены :)
Я вот так ни разу и не заюзал наследование чего-то кроме stdin/stdout/stderr после exec'а (не путаем с годным и полезным наследованием хендлов после fork'а). От него одни проблемы были.
как правило stdin/stdout хватает за глаза.
давеча из простого приложения сделал сервак, который можно просто слэйвом, дочерним процессом, запустить. раньше оно просто интерпретировало комманды из параметров коммандной строки (и результаты на stdout писало), но парой легких движений добавил чтение комманд из stdin'a. больше всего работы было объяснить коллегам зачем это нужно. а после того как пару часов спустя все сделал - все сразу впечатали. они оказывается уже пару лет хотели сделать демона, но откладывали потому что как выяснилось не знали простых и дешевых способов как это сделать и думали что там 2-3 недели работы.
Даже про демона интернета не знали?
Я через него вот такое простенькое апи ваял: http://govnokod.ru/16668. С внутреннего сайта ajax'ом дергается...
Нет. Но там бы и не помогло, потому что стартап как минимум ~300ms (чтение ДБ из медленного (но надежного) флеша, плюс проверка CRC). И как раз это время народ и хотел урезать.
> Я через него вот такое простенькое апи ваял
А я тут давеча на sed/awk из вывода sqlite делал JSON для AJAXового веб интерфейса. :)
А, там локальный демон нужен был, ясно. Ну здесь минус - только один процесс может подцепиться к такой базе. Но, видимо, там он только один и есть в каждый момент времени?
по уму нужен демон. но кастомер не хочет платить и есть другие технические проблемы. (демон нужен уже в базовой системе - но есть грабли с опциональными компонентами. поэтому в текущий момент тулзов как бы виртуально несколько: в зависимости от конфигурации железа и установленого софта берется нужный бинарник с вкомпилированой структурой базы. теоретически есть еще и библиотека, но она лежит в другом проекте, и пока не умеет динамически грузить модели данных. проблема что все это богатство нужно только на стадии разработки и отладки. почему кастомер и не хочет платить.)
Хм, а как это реализовано через stdin/stdout? Они перенаправлены на никсовые fifo, чтобы несколько процессов могли зацепиться одновременно?
перед выполнением комманд, берется (глобальный) лок, проверяется секвенс нуммер (и если он поменялся, база перечитывается), и комманда выполняется. если комманда что-то меняет в базе, то секвенс нуммер инкрементируется. результат всегда идет на stdout.
т.к. это нужно для разработки, то столкновения на локах происходят редко, и самая главная часть которую делали раньше это секвенс нуммер, для определения паралелльных изменений.
Я пока встречал один такой пример - горячий рестарт сишной проги без потери коннектов(!) в uwsgi.
я делал то же самое. в моем случае это была встроеная софтина и делал я это для облегчения разработки. (раз в секунду проверял если экзешник поменялся, и если да, выключал главный цикл что бы новые комманды не получать, ждал пока все пендинг комманды выполнятся и ответы пошлются, и потом просто делал exec() на самое себя.)
если память не изменяет, список номеров хэндлов передавал в специальной переменной окружения.
на ПЦ крутилось 3-4 виндовых прог которые подключались по сети к этой софтине. если соединение обрывалось, они кидали много сообщений, ругались и прочее, и требовалось несколько минут что бы всё вернуть назад в рабочий порядок.
времени экономило кучу.
понятно что не энтерпрайз. куда мне до таких высот.
Скольки % девелоперов?
Не минусите, как слоны!