The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Решено с 2035 года приостановить синхронизацию мировых атомных часов с астрономическим временем, opennews (??), 21-Ноя-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


26. "Решено с 2035 года приостановить синхронизацию мировых атомн..."  +/
Сообщение от Аноним (26), 21-Ноя-22, 11:14 
> Неужто нельзя сделать чтобы одна из секунд просто по факту дольше длилась

Теперь представим что какой-то критичный процесс использовал секунду как наихучший таймаут в качестве какой-то аварийной реакции. А тут опа - аж две! Что там будет дальше - да кто его знает, в хучшем случае что-нибудь взорвется, сгорит, перевернется кверху стабилизаторами, или что там еще интересного в технике бывает когда допущения програмеров не совпали с тем что есть.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

38. "Решено с 2035 года приостановить синхронизацию мировых атомн..."  +/
Сообщение от Аноним (135), 21-Ноя-22, 11:43 
У тебя критичный процесс поди ещё и от строковых названий дней недели зависит?
Ответить | Правка | Наверх | Cообщить модератору

76. "Решено с 2035 года приостановить синхронизацию мировых атомн..."  +2 +/
Сообщение от Аноним (-), 21-Ноя-22, 14:18 
> У тебя критичный процесс поди ещё и от строковых названий дней недели зависит?

У меня не зависит, но судя по вон тем упоминаниям про нагрузку на CPU... после 2035 ожидается много странной фигни. Если сейчас баговали одни, а нормально работали другие, они теперь поменяются ролями, как в анекдоте про хрыча и запорожец. Ну а вы сможете задвинуть вашу коронную фразу, как тот дед.

Ответить | Правка | Наверх | Cообщить модератору

159. "Решено с 2035 года приостановить синхронизацию мировых атомн..."  +/
Сообщение от Аноним (159), 21-Ноя-22, 20:32 
Да просто это два разных времени, для двух разных задач.

Для критичных локальных realtime задач нужно строго монотонное время в системе отсчёта программно-аппаратного комплекса. Тут вообще можно отсчитывать микросекунды от времени запуска системы, синхронизация если какая-то и нужна, то микроскопическая между узлами кластера в локальной сети. Этому времени совершенно ни к чему измеряться в общепринятых в быту единицах типа месяцев или лет.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

211. "Решено с 2035 года приостановить синхронизацию мировых атомн..."  +1 +/
Сообщение от Аноним (135), 22-Ноя-22, 06:50 
Именно это всё уже есть в линухе, куча часов одновременно тикают с разными свойствами и настраиваемостью.
Ответить | Правка | Наверх | Cообщить модератору

299. "Решено с 2035 года приостановить синхронизацию мировых атомн..."  +/
Сообщение от Аноним (299), 22-Ноя-22, 22:44 
jiffies с зависимостью от HZ/USER_HZ - это всё же несколько непрактично для чисто прикладного ПО. Хотя поверх этого сделать вменяемый API несложно. Но это, конечно, в любом случае не спасет от типичного индуса со sleep(10) // fix race condition
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру