Вовсе так не выглядит, как вы описали. Компании предоставили сервис и брали (или не брали за них деньги). Вам ничего не продавали такого, что можно забрать домой. Это как покупать билет на автобус. Все равно что жаловаться на то, что вы каждый день ездили на автобусе по маршруту 264, а потом одним прекрасным днем выяснилось что компания не будет больше подавать автобусы по этому маршруту и предложила найти альтернативы. По вашей логике компания должна раздать автобусы, которые они закупили за свои деньги.
В продукт вкладывают силы, деньги. И не каждый владелец алтруист настолько, чтобы отдать на балго общества код, которым могут, кстати говоря, воспользоваться конкуренты и развить свои продукты.
Сугубо субъективно. На одной из фоток видно, как отражается окно на противоположной стороне доски. Это первое что мешает чтению текста. Второе. что затрудняет — отражение творческого порядка на столе, на той же фотографии.
1) идентифицировать разделяемую область неким символичным именем, к примеру "/mySharedMem"
2) с помощью shm_open открыть файловый дескриптор на только что идентифицированной области
3) ftruncate'ом задать необходимый размер сегмента
4) с помощью mmap мапировать этот сегмент в свое адресное пространство
Я полностью с вами согласен, иначе поле «в избранных у… человек» тоже не будет показательным.
Я не предлагаю заносить в избранное все статьи, за которые вы автору хотите сказать «Спасибо». Я как раз говорил о том, что если статья у кого-то в избранных, то, по моему скромно мнению, это для автора больше значит, чем миллион случайных спасибо от читак, которые о вас никогда больше не вспомнят.
Что бы вы предпочли, увидеть 200 раз нажатой кнопку «спасибо» за свою статью или 10 раз нажатой кнопку «в избранное»? Лично для меня ценней знать что статья пригодилась. И именно это отображается полем «в избранном у N человек».
Я в таких случаях себя ставлю на место разработчика и представляю как это неприятно получать дырку от бублика за такую классную игруху. Во время самого геймплея рекламы нет, смысл отключать?
Когда нужно подумать что сделать и где ошибка, то, само собой, в этот момент кодить неудобно. А вот когда уже все обдумано и ошибки пока не встречены, то порой не хватает время на чашечку кофе. Бывали случаи без обеда оставался, когда «на волне».
Вобщем вот что я накопал для вашего вопроса:
1. Стандарт POSIX утверждает что если имя нашего семафора начинается со слеша, то любой вызов sem_open с таким именем в любой процедуре должен возвращать дескриптор одного и того же семафора. Проще говора вызов sem_open("/semaphore",...) в любой процедуре вернет дескриптор одного и того же семафора. Тот же стандарт пишет, что если слеша в начале имени нет, то поведение стандартом не описывается, а ложится на плечи разработчиков sem_open. Проще говоря, что делать с именем семафора без слеша в начале «решает» конретная реализация sem_open.
2. Я не поленился глянуть в реализацию sem_open в стандартной библиотеке glibc. Так вот тамошняя реализация функции допускает отсутствие слеша. Более того, sem_open не пользуется слешом в начале имени, а смело его пропускает вот таким наглым образом:
sem_t * sem_open (const char *name, int oflag, ...) {
…
/* Construct the filename. */
while (name[0] == '/')
++name;
…
3. Ответ на ваш вопрос: имя семафора должно начинаться со слеша, скорее всего, потому, что семафор, как и разделенная память, должен создаваться в файловой системе ОС. Выглядеть это должно примерно так: /dev/sem/my_semaphore_name. Именно так реализовано в системе QNX, которая, к слову сказать, является полностью POSIX совместимой, в отличие от Linux.
Сходу могу только сказать, что необходимость слеша в начале имени семафора продиктована требованиями POSIX стандарта. Почему это так, я сейчас не могу сказать. Обещаю поискать больше информации по этому поводу и ответить на ваш вопрос.
У pipe нет имени и он создается для единичного использования. Пайп создается в рамках одного процесса и pipe могут использовать только наследники этого процесса. Самый простой пример — «cat some_file | grep some_name». Здесь пайп создается шеллом, в котором запущена команда.
В отличие от pipe, fifo создается именованным и выглядит как обычный файл в системе Linux, с некоторыми оговорками. Доступ к fifo могут иметь кто угодно, кто имеет соответствующие привилегии.
Вот пример fifo:
prwxr-x--x 1 serge users 0 Jun 18 13:43 my_named_pipe
А, вон вы о чем. Я в начале сделал оговорку, что не могу ни в каком виде упоминать закрытый протокол, ни как он выглядит, ни тем более выкладывать диссектор для него. В противном случае меня затаскают по судам. Сейчас это модно. :-)
Тот диссектор, который я писал для работы, распространяется внутри компании. Поэтому те, кому он может понадобится, уже с ним работают.
main.Struct2{A:0}instead ofmain.Struct2{A:1}since A is not initialized.Явного указания в правилах сервиса не видел.
Возможно можно через клиент загрузить файл больше. Но для меня это не вариант, так как 1) Нет клиента под Linux.
2) Размер загружаемых файлов ограничен размером 2GB.
В продукт вкладывают силы, деньги. И не каждый владелец алтруист настолько, чтобы отдать на балго общества код, которым могут, кстати говоря, воспользоваться конкуренты и развить свои продукты.
1) идентифицировать разделяемую область неким символичным именем, к примеру "/mySharedMem"
2) с помощью shm_open открыть файловый дескриптор на только что идентифицированной области
3) ftruncate'ом задать необходимый размер сегмента
4) с помощью mmap мапировать этот сегмент в свое адресное пространство
Чтобы не быть голословным, сравните:
gadgets.masterkit.ru/product/23.htm
www.dealextreme.com/p/driving-anti-drowsy-alert-2503
Будте бдительны.
Я не предлагаю заносить в избранное все статьи, за которые вы автору хотите сказать «Спасибо». Я как раз говорил о том, что если статья у кого-то в избранных, то, по моему скромно мнению, это для автора больше значит, чем миллион случайных спасибо от читак, которые о вас никогда больше не вспомнят.
Что бы вы предпочли, увидеть 200 раз нажатой кнопку «спасибо» за свою статью или 10 раз нажатой кнопку «в избранное»? Лично для меня ценней знать что статья пригодилась. И именно это отображается полем «в избранном у N человек».
1. Стандарт POSIX утверждает что если имя нашего семафора начинается со слеша, то любой вызов sem_open с таким именем в любой процедуре должен возвращать дескриптор одного и того же семафора. Проще говора вызов sem_open("/semaphore",...) в любой процедуре вернет дескриптор одного и того же семафора. Тот же стандарт пишет, что если слеша в начале имени нет, то поведение стандартом не описывается, а ложится на плечи разработчиков sem_open. Проще говоря, что делать с именем семафора без слеша в начале «решает» конретная реализация sem_open.
2. Я не поленился глянуть в реализацию sem_open в стандартной библиотеке glibc. Так вот тамошняя реализация функции допускает отсутствие слеша. Более того, sem_open не пользуется слешом в начале имени, а смело его пропускает вот таким наглым образом:
sem_t * sem_open (const char *name, int oflag, ...) {
…
/* Construct the filename. */
while (name[0] == '/')
++name;
…
3. Ответ на ваш вопрос: имя семафора должно начинаться со слеша, скорее всего, потому, что семафор, как и разделенная память, должен создаваться в файловой системе ОС. Выглядеть это должно примерно так: /dev/sem/my_semaphore_name. Именно так реализовано в системе QNX, которая, к слову сказать, является полностью POSIX совместимой, в отличие от Linux.
В отличие от pipe, fifo создается именованным и выглядит как обычный файл в системе Linux, с некоторыми оговорками. Доступ к fifo могут иметь кто угодно, кто имеет соответствующие привилегии.
Вот пример fifo:
prwxr-x--x 1 serge users 0 Jun 18 13:43 my_named_pipe
Тот диссектор, который я писал для работы, распространяется внутри компании. Поэтому те, кому он может понадобится, уже с ним работают.