Yana bir qiziq challenge.

Tassavur qiling biz bir filega Nta processdan turib content yozyabmiz va bu holatda race condition bo'lib contentlar kasha bo'lib tushish shansi bor. Masalan Process 1 hali yarmini yozib bo'lmasadan process 2 yozishni boshlaydi vaxakazo.

Ho'sh ushbu masalani qanday hal etsak bo'ladi ?

Hayolga keladigan eng sodda misollar quyidagicha.

1. File locking, bu huddi mutexlarni FSdagi versiyasiga o'xshaganroq conceptda ishlaydi. Lekin muammosi agar ko'p concurrent jobs bo'lsa deadlocks. Lekin garantiya beradi kernel darajasida.

2. Posix based systemlarda ham file denoscriptorda atomic operations qilsa bo'ladi. Masalan file desriptorni append modeda ochish orqali atomic writelar qilsak bo'ladi. Muammosi max buffer size 4KB.

3. Temp files, masalan har bir process alohida temp file ochadi va kegin safe merge qiladi. Muammosi consistencyga o'zingiz javob berishingiz kerak asosan.

4. Stariy dobriy centeralized mexanizmlar masalan bitta socketda eshitib turamiz va writelar shu socketga bo'ladi socket esa filega yozadi. Ammo over operations.

Bizni relago journalga barmoq bilan sanagulik darajadi processlar ulanadi. Shu sababli bizga mos keladigan va osonroq bitadigan ish bu albatta file locking mechanism. Resurs kam yeydi keginchalik mmap qivolish ham oson va eng muhimi read va write streamlar alohida bo'ladi shu sababli chala loglarni read qilish kabi narsalarga ham duch kelmaymiz. Agar bizni journal entrylar 4kb dan kam bo'lganida atomic qilar edik lekin bunga aniq garantiyalar yo'q xozircha write agnostic qilib entryni chunksdan yeg'ib oladigan qilsa bo'ladi lekin unga oldin max 4kblik buffer qilish kerak hullas ish ko'proq. Qolgan yechimlar esa yoki perfomance issue yoki bo'lmasam optimizatsiya uchun ko'proq code yozish kerak va ularning natijasi ham noaniq.

References:
https://gavv.net/articles/file-locks/
https://www.diskodev.com/posts/linux-atomic-operations-on-files/
https://pvk.ca/Blog/2021/01/22/appending-to-a-log-an-introduction-to-the-linux-dark-arts/

Guys tez maynerlarni o'chiramiz.

https://letsencrypt.org/2026/01/15/6day-and-ip-general-availability.html

Hash funksiya nima deysizmi ?

Masalan biror murakkab qurilmani qiziqib ochasiz va barcha detallarini ajratib qo'yasiz, kegin birdan aralashtirvorasiz hammasini. Manashu holat o'sha qurilmaning hashed versiyasi.

Biroz intro qilishga shuni o'qisangiz bo'lsa kerak: https://tuttlem.github.io/2024/10/26/simple-hashing-algorithms.html

Naxren leetcode agar bunaqa narsalarni hayotga tadbiq qilmasangiz Qo'chqor aka!

Bu yerda esa yanada qiziqroq ma'lumot bor: https://binarymusings.org/posts/rust/rust-hashmap-memory-layout/

Bu yerda SMID bilan qilingan focuslar: https://kylematsuda.com/blog/writing_a_hashmap_part_3a

File locking cooked

Dromatic: f*ck sleep keep coding!
Realist: f*ck coding keep sleep!
Me: f*ck sleep and coding keep shitposting.

Haskell Haskell Haskell!

https://www.youtube.com/watch?v=ETxmCCsMoD0&list=RDETxmCCsMoD0&start_radio=1

WTH man ?

Man nix discourseni ochdim va asablarim tugadi.

Man ko’rgan birnechta dasturchilar turlicha commitlar qilishadi PRga. Mana yana qiziqlaridan biri :)

FAFO deriving custom typeclass.

Hullas bungacha manda journal entry Key Val dan tashkil topgan edi. Manabunday:

let entry = Entry::new(vec![
            Field::string("_SYSTEMD_UNIT", "myapp.service"),
            Field::string("PRIORITY", "6"),
            Field::string("MESSAGE", "Application started"),
        ]);

Ammo bu narsa yomonam noise beradi. Rustda ham Haskell kabi derive qilsa bo'ladi typeclasslarni. Shu ideya hayolga keldi. Yani manabunaqa qilsa bo'larmikan ?

#[derive(JournalEntry)]
pub struct ServiceLog {
    #[journal(rename = "_SYSTEMD_UNIT")]
    pub unit: String,

    #[journal(rename = "MESSAGE")]
    pub message: String,
    #[journal(rename = "PRIORITY")]
    pub priority: u32,
}

Agar shunaqa bo'lsa man o'zim yasagan tipni osongina journal entryga ham o'gira olaman shu bilan birga type safety ham joyida qoladi. Undan tashqari log entrylar tag bilan ajratilgan bo'ladi constructor namega qarab bu esa journalda grouping kabi narsalar qilishga juda foydali.

Haskellda siz yozgan typeclassni derive qilish unchalik qiyin emas. GHC.Generics bilan ishingiz anchagina oson ham bitadi, bu mavzularda juda ko'p resurslar bor. Lekin rustda esa bunday mavzular haqida kerakli resurslar deyarli topolmadim. Topganim bitta shu HeapSize. Ishqilib anchagina FAFOlardan kegin bu narsani yedirdim vanihoyat man yozgan typeclassni derive qilsa bo'ladigan bo'ldi.

Implementation: https://gist.github.com/lambdajon/c815ea20b9743e69fba9911e7583d930

Aytgancha

FAFO -> Fuck Around and Find Out

Rust fichalaridan foydalanib nafaqat safe balki declarative va qisqaroq code yozsa bo'ladi.

Bunga sekin sekin ko'nikish kerak. Masalan shu macro bilan ancha user friendly bo'ldi. Undan tashqari boshqa narsalar ham bor, bazida ko'p narsani boilerplate qilib yuboramiz.

Refactoring sessiyalarini shunga ham ko'paytirmoqchiman. Shu orqali o'rganamiz har bir masalaga intensiv yondoshuvni. Agar language feauturelardan foydalanmasak Rustda yozgan bilan C++ da yozganimiz farq qilmasligi mumkin. Agar biz shunday train qilib yursak, yangi narsalarga ko'proq tolerant bo'lsak shunda Codeni AI yozberadimi yoki o'zimiz yozamizmi doyim ham katta axamiyatga ega emas. Chunki biz aynan qanday codeni qabul qilishni bilamiz aks holda AI generate qilib bergan har qanday kodni ishlataveramiz va yetmaganiga o'zimiz yozgan govnokodlarni AIga review qildiramiz.

Haskell yoki Rustga o'xshagan tillarda optional tiplarga duch kelasiz. Imperativ tillardagi NULL o'rniga ko'proq manashunday abstraksiyalar ishlatilinadi.

Haskell: Maybe
Rust: Option

Bu abstraksiyalar bizga optional valuelar bilan ishlagani kerak, imperativ tillarda aytganda nullable valuelar bilan. Ammo bilamizki imperativ tillarda null hamma joyda osilib yuradi, niz nullable valueni olib yana boshqa funksiyaga bervorishingiz mumkin vaxakazo hullas hamma joyda null tekshirish potensiali mavjud.

Immutable tilda ishlar ekansiz imperativ tillardagi odatlarni sekin chetga surish kerak. Optional narsalarni eng boshidan hal etish kerak. Bo'lmasa o'zingizni Option tipni ham qurib o'tirasiz.

Bu draft PRda aynan shu muammoni yechimini ko'rsak bo'ladi: https://github.com/bleur-org/bleur/pull/17/changes

Ammo muammo bundanda kengroq ekan, Biz Configuration degan tipda Empty degan varianti olib tashladik va endi bizda Configuration tipida empty case yo'q. Lekin muammo shundaki uning Template yoki Collection tiplariga kerakli valuelar Collection tipi construct bo'lish vaqtida bo'lmasligi mumkin.

Manashu sababli konstruksiyalar yanayam teparoqdan refactor qilinishi kerak, PRda aynan todo qolib ketgan.

PR o'ziga etibor bersangiz birgina empty case sababli qancha code kerakmas bo'lib qoldi. Shu sababli ham bunday holatlarda o'zingizni custom empty caseni qurmaslik kerak. Eng boshidan aniq ajratib olish kerak hammasini shunda ortiqcha code bo'lmaydi, ortiqcha unwrap ham bo'lmaydi. Vaqtim bemalol bo'lganida PR yakunlab qo'yaman va natijani ulashaman.

Maxsus empty caselar bazida bo'lishi mumkini ammo bu boshqa mavzu bizni contextga umuman aloqador emas.

Manashu ham misol bo'ladiki biz language feauturelardan foydalanishni o'rganishimiz kerakligiga. Albatta hammasini sekin sekin o'rganamiz.

Bu ishlardan tashqari vaqtim bo'lganida yangi ish muhitimni ham boshlamoqchiman. Nix va linuxni biroz custumize qilamiz anchadan buyon o'zim istagan text editor vaxakazolar.
Orada qiziq narsalar chiqsa ularniyam gaplashamiz.

Imkon bo'lsa unda ham har bir o'zgarishni share qilaman, masalan nega falon narsani tanladim, qanaqa optionlar bor edi vaxakazolar.

Tiplarni journalga implement qilishga bitta sabab topdim.

1. Loglarni render qilish kerak. Journalga hohlagancha narsa yozib tashlayverganingiz bilan hali muammoni report qilinganda o'sha journalni view qiladiganlar ham tushuna olishi kerak.
2. Reportdan olingan dump file ichida aniq duplicated narsalar bo'ladi, masalan muammo kernel oops bilan boshlandi va shu sababli boshqa joylarga ham tasir qildi, natija tizimda nimadurlar buzildi lekin bunaqa holatda loglarni ko'rsangiz doyim ham bitta bo'lmaydi yani sabablar zanjiri. Demak journalni indexlay olish muhimroq ammo indexlar read journal qilinganda bo'lmaydi mavjud journal data fileni o'qib undan index yasash kerak va bu yaqin kelajakda bo'ladi.

Bu holatda esa eng boshlang'ich yechim journal entrylarga tiplar qo'shish. Ho'sh qanday bo'ladi ?

Yechimlar unchalik qiyin emas hayolga 2tasi keldi.

1. Har bir field o'zini tipiga ega bo'ladi. Bunda boshlang'ich 1 yoki 4 byte offset type representation bo'ladi. Masalan 1 kelsa 32bit int, 2 kelsa 64, 3 kelsa string vaxakazo.

2. Bufferlar indexlari bo'yicha type schemalar. Bu holatda biz har bir entryga metadataga schema qo'shib ketamiz. Masalan bizni entryda 3ta field bor. Metadatagi N byte tuple bo'ladi va u yerda schema turadi: (3,3,2) Bu yerda entry field order o'zgarsa ham farqi yo'q kombinatsiyalar mos kelaveradi.


Yana bir biroz murakkabroq va chalaroq fikr bor ammo potential storage efficient, recorda tag bor yani type constructor tag bo'lib olgan. Aslida bu unchalik tog'ri ham emas chunki code o'zgarishi mumkin va turli tillarda constructor namelar turlicha. Shu sabab shunchaki strukturani identity qilish kerak hayolga birinchi kelgan yechim bu Duck typing. Ammo bizda juda muhim nuans shundaki journalni oddiy user journalni o'qimaydi, shu sababli biz auto indexing qilsak bo'ladi. Masalan journal dump yuborilganidan kegin bizga kelib tushganida alohida indexing bo'ladi. Yani xinux ishlayotgan joyda indexlash vaxakazolarga umuman extiyoj bo'lmaydi uyoqda hamma narsa write oriented bo'ladi. Lekin journal bizga kelganida biz uni o'qishdan oldin read oriented qilib olamiz )). Xozircha bu narsa biroz hom, agar fikrlar bo'lsa aytilar.

Me