← All posts tagged posix

OCTAGRAM
posix iconv If the character encoding of the input is stateful, the iconv() function can also convert a sequence of input bytes to an update to the conversion state without producing any output bytes; such input is called a shift sequence.
Пытался понять, iconv отказывается есть всё только когда наезжает на шляпу или для неполных последовательностей тоже. Насколько я могу понять это “can also”, как хочет, так себя и ведёт.
OCTAGRAM
pthreads Strategies for Implementing POSIX Condition Variables on Win32

Заставил себя вчитаться. Вчера заснул после PulseEvent, сегодня со свежими силами продолжаю читать про SetEvent. Хотел написать, что никак не могу понять эту часть:
8. Thread C2 is the only thread left and blocks forever since not_empty_ will never be signaledПока писал, почему не могу понять, понял.

То, что в этой статье описывается, как пользоваться WinAPI времён XP, не принципиально.

Во-первых, во второй части указано, как реализовывать события, если их нет, и как реализовывать мониторы поверх событий, если в операционной системе нет атомарного ожидания одного объекта и сигнализации другому (Windows 95, Windows NT 3.51).

Во-вторых, я читаю, как сделан M:N планировщик IBM NGPT, и там тоже поверх событий сделано: на строке 333 ожидание входа в мьютекс, а на строке 998 — ожидание условной переменной, а откуда берётся ev, можно посмотреть по строкам выше.

Это отличается от того, что пишет, например, Дмитрий Завалишин, разработчик Фантом ОС, под авторством которого вышло научно-популярное чтиво про архитектуру примитивов синхронизации:
Иерархия реализации такова: mutex/cond/sema сделаны на базе спинлоков, спинлоки — на базе атомарных операций, предоставляемых процессором.
Внутри ядра мьютекс реализован с помощью спинлоков, а вот спинлоки реализованы сами по себе, автономно. Они — действительно базовый примитив. Ниже — только сам процессор.

Смотрю его код и вижу не событие, а некую очередь, которая то ли так же, как события, работает, то ли нет, но неплохо бы, чтоб это где-то уточнялось. Разработчик osFree, когда я его на эту тему пытал в IRC, говорил, что у них в L4 сообщения посылаются между процессорами.

То есть, восполняя пробелы:
mutex/cond/sema сделаны на базе спинлоков и либо событий, либо очередей потоков, либо сообщений.
События, очереди потоков или сообщения реализованы на базе спинлоков и атомарных операций, предоставляемых процессором.
Спинлоки реализованы на базе атомарных операций, предоставляемых процессором.

Напрашивается предположение, что между подчёркнутым есть изоморфизм или даже синонимия, но сам я такого утверждать не могу, а чтоб где-то авторитетно утверждалось, не вижу. Если про эту часть даже тот, кто сам её писал, «забыл», что говорить о других.
OCTAGRAM
время posix ada GNAT FILETIME Разобрался с конвертацией времени. Как выясняется, в GreyLink DC++ время хранится совсем не в том формате, в котором я подумал, а в FILETIME. Также выяснилось, что и FILETIME в Windows, и time_t в POSIX могут быть как с високосными секундами, так и без. FILETIME, похоже, с високосными секундами не встречается, но тут пишут, что это не исключено. time_t согласно POSIX.1 тоже не должен поддерживать их:
IEEE Std 1003.1-1988 (``POSIX.1'') legislates that a time_t value of 536457599 shall correspond to "Wed Dec 31 23:59:59 GMT 1986." This effectively implies that POSIX time_t's cannot include leap seconds and, therefore, that the system time must be adjusted as each leap occurs.… но я смотрю на маны posix2time и time2posix и вижу, что совместимость с POSIX где-то может быть сломана в угоду монотонности времени. Всегда надо уточнять, с високосными секундами время или нет, иначе будет разъезжаться на 25 секунд, и с каждым годом всё больше. Вот, допустим, MySQL поддерживает високосные секунды в полях TIMESTAMP, если работать с этими значениями через функцию UNIX_TIMESTAMP. Но как мы уже выяснили, подлинный UNIX time_t не содержит високосных секунд, значит, это может быть только модифицированный. И если вы создаёте значение инструментом, который не вставляет эти секунды, у вас время начнёт разъезжаться. Вот в JavaScript по стандарту временная шкала нелинейная, как и в POSIX.1. Но если POSIX.1 где-то нарушается, то, может быть, и EcmaScript тоже? Давайте проверим:
OCTAGRAM
P2P время Выписал реальные значения временных меток в атрибуте Shared (GreyLink DC++) и TS (FlyLink DC++). Для сравнения ещё вычислил Date.now(), он получился по длине между ними. Для наглядности добавил подчёркивание там, где кончаются секунды.
GreyLink DC++: 1307966464_52889830
Date.now(): 1480931727_080
FlyLink DC++: 1295288944
Таким образом, это в общем везде время от начала Эпохи (1970), но во FlyLink DC++ — с точностью до секунды, а в GreyLink DC++ — с точностью до 10 наносекунд. Я опасался, что там время OLE Automation (от 1900) может затесаться.

Правда, тут есть один нюанс. Согласно POSIX, время отсчитывается без учёта високосных секунд, а вот справедливо ли это по отношению к каждой из трёх приведённых дат, не очевидно. Надо полагать, что всё-таки без.
OCTAGRAM
far Win8 В Windows 7, если я изменил ярлык Far Manager, добавил ключ /w, чтоб ему размер можно было менять нормально, то запущенный через этот ярлык Far Manager ведёт себя как положено, а если создавать новые окна щелчком средней кнопки мыши по группе окон, то они создаются без /w почему–то, так что приходится добавлять Quick Launch панель и дальше как по старинке. А вот в Windows 8 модифицированный ярлык создаёт другую группу окон, и в этой другой группе новые окна создаются с /w. Это победа!
Хотя было бы лучше, если бы в Far это поведение было по умолчанию. Или программные интерфейсы консоли стали чуть ближе к изменяемым виртуальным терминалам POSIX.
OCTAGRAM
posix WebRTC Была для TCP/IP такая полезная утилитка netcat. А потом все повадились ходить через SOCKS, и даже были сети с forced proxy socks. Без SOCKS стало никуда, и тогда был сделан socat. А сейчас все за NAT, Teredo не настроен, и стало никуда без WebRTC. Теперь нужен новый *cat.

Меня огорчает, что я так и не нашёл ни одной реализации Interactive Connection Establishment для libuv
OCTAGRAM
Windows programming pthread cs.wustl.edu

Both Win32 events and POSIX condition variables provide similar waiting, signaling, and broadcasting features. For instance, WaitForMultipleObjects can acquire a mutex and wait on an event simultaneously via the waitAll flag and SignalObjectAndWait can release a mutex and wait on an event atomically. These functions provide semantics akin to the pthread_cond_wait and pthread_cond_signal. Thus, there are instances where either events and condition variables can be used interchangably.
However, extreme care must be taken with Win32 events to ensure that there are no race conditions introduced when switching from one mechanism to another. Unfortunately, there's no way to release just one waiting thread with a manual-reset event. Likewise, there's no way to release all waiting threads with an auto-reset event. This limitation is a major source of difficulty when implementing condition variables, as shown in Section 3.
After years of repeatedly seeing Win32 implementations of condition variables posted in newsgroups like comp.programming.threads it became apparent that many Win32 implementations are either incorrect or contain subtle problems that can lead to starvation, unfairness, or race conditions. To help developers avoid these problems, this article evaluates common strategies for implementing POSIX condition variables on Win32, illustrating common traps and pitfalls and ways to avoid them.