Partida e segurança
Partida e segurança: o mapa Item por item das partes 13 e 15 da referência Deep Tech — bootstrapping, TLS, pilha, globais, modelo de segurança e unsafe.
Item No DataForge Onde runtime initialization as sete fases, nomeadas e em ordem A partida static constructors comptime — roda na carga, numa caixa sem E/Scomptime global variables steady, e o hoisting das declarações de topoA partida runtime services os adopt, cronometrados um a um A partida boot / loader, stack setup, stack probes não se aplica : quem faz o boot é o CPython—
Item No DataForge Onde thread-local variables I.local / I.meuPor thread TLS initialization uma ação que constrói o valor, uma vez por thread Por thread TLS destructors ao_terminar, quando a thread é coletadaPor thread runtime thread state _por_thread no interpretador: pilha e profundidade já eram por threadPilha thread-local allocators não se aplica : quem aloca é o CPython—
Item No DataForge Onde stack frames I.quadros() — ação, linha e arquivoPilha stack overflow detection teto de mil quadros, com as duas saídas na mensagem Pilha coroutine / fiber stacks as fibras são sem pilha Fibras stack allocation, probes, guards, growth não se aplica : a pilha é a do CPython—
Item No DataForge Onde static/constant initialization steady, e comptime para o que é calculadocomptime lazy initialization o modificador lazy em campo de blueprint Modificadores initialization ordering a ordem do arquivo; ciclo é erro do `check` , com a cadeia inteira na mensagem Carga destruction defer de topo roda no fim, na ordem inversaA partida global constructors (C++) não se aplica —
Item No DataForge Onde memory safety por construção : não há ponteiro na linguagem, e o coletor responde pela memória. A exceção é `Arcane.C` , e ela é declaradaFFI type safety dataforge check, que atravessa arquivos Análise thread safety não automática, e medida : duas threads escrevendo no mesmo nome perderam 40.425 de 80.000. O check avisa (escrita-concorrente), e Arcane.Stm dá escritas que acontecem juntasSTM bounds checking em execução sempre, e antes de rodar quando se prova (indice-fora-do-alcance) Análises null safety ??, ?., e o talvez-nao-definida do fluxoAnálises integer overflow policies não há overflow : o inteiro é de precisão arbitrária. Uma classe inteira de bug não existe aqui — e o preço é a conta ser mais lenta que uma de 64 bitsTipos resource safety `Arcane.Posse` : liberação determinística, e o check cobra o recurso não soltoPosse capability boundaries Arcane.CapacidadeCapacidade
Item No DataForge Onde raw pointers, manual allocation Arcane.C: ponteiro, alocar, liberarPonteiros FFI o módulo inteiro é a região insegura FFI minimizar regiões unsafe não há bloco unsafe a marcar: o módulo é a fronteira , e a documentação diz isso em vez de espalhar uma palavra pelo código FFI validar entradas a assinatura é declarada e a lista de tipos é fechada; o ponteiro nulo é conferido Chamar C encapsular APIs inseguras P.com(P.dono(C.alocar(n), …)) — o bloco sai no fim do escopo, inclusive no caminho de erroPonteiros documentar precondições expects / promises / invariant, cobrados em execuçãoContratos assembly, SIMD, MMIO, kernel não se aplica — ver o mapa de hardware —
A parte 13 rendeu o que dependia do runtime da linguagem (fases visíveis, TLS com finalizador, a pilha que se pergunta) e deixou de fora o que é do CPython (boot, stack probes, guards). A parte 15 já estava quase toda pronta — segurança de memória é por construção, e a ausência de overflow de inteiro elimina uma classe de bug inteira —, e o que faltava era a fronteira de capacidade , que agora existe com os limites escritos em voz alta.
Anterior
← Fronteira de capacidade
Próximo
Hardware: o mapa →