chrdcv escreveu:Marcelo Sam* mais uma vez, obrigado pela ajuda. No resto das minhas férias escolares de julho, trabalharei mais no código e postarei os resultados para crítica (caso tenha tempo e disponibilidade para dar uma olhada seria muito bom alguém com a tua experiência ir passando algumas dicas interessantes a serem adotadas).
Uma coisa que venho pensando refere-se a multiprocessamento. Como a Glibc e a libc adaptaram-se aos "novos" tempos? Houve re-escrita?
acredito que a ideia da libc era suprir a ponte entre aplicacao e sistema operacional, de modo que eh uma das poucas bibliotecas que realmente possui os handlers para pular para o kernel.
entao eh meio que fatidico que ela precisa sempre ser atualizada conforma os paradigmas mudam. e olhando na sua versao inicial, dah para ver que era bem simples: suportava arquivos, terminais e algumas funcionalidades basicas. na decada de 80 a libc se ramificou em duas grandes vertentes: a que acompanhava o bsd e a que acompanhava o unix. no caso do bsd, o grande quebra inicial foi a stack ip: ela se moldava como uma adicao a libc, de modo que, depois de abrir um socket de rede, ele funcionava tal como um descritor de arquivo normal, via read/write. o unix, por outro lado, adicionou o suporte a streams, que eu francamente nao sei exatamente como funciona. tem um nome que a gente conhece, mas acredite, nao eh exatamente isso. mais ainda, o bsd tambem era um unix, de modo que o unix acabou virando o sysv (system v), assim vc tinha o unix bsd e o unix sysv... hehehe enfim, mais tarde o sysv adicionou o suporte a ipc (comunicacao interprocesso), que jah fazia frente melhor aos sockets do bsd. no final da decada de 80, porem, houve um movimento para unificar as coisas, de modo que uma aplicacao desenvolvida para unix funcionasse tanto no bsd quanto no sysv. isso obviamente impactou a libc drasticamente, que precisava suportar os diversos sabores do unix, mas facilitou a vida para portar aplicacoes.
e embora multiprocessamento fosse algo suportado no kernel, a granularidade era em nivel de processos. assim, nao havia impacto em aplicacoes ou na propria libc. porem no fim da decada de 80 surgiu o conceito de threads: vc poderia ter um microkernel com suporte a threads e em cima dele podia colocar um kernel unix (bsd ou sysv) e sua respectiva libc. o problema daih eh que a granularidade poderia ser de threads dentro de processos, o que impactava tanto a aplicacao quanto a libc. acho que foi o maior redesenho da libc incluir o suporte a threads, pq afeta essencialmente tudo: imagine duas threads acessando o mesmo arquivo ao mesmo tempo! tem que ter certas restricoes para evitar o caos... em especial, o arquivo do usuario que se dane, mas nao pode-se deixar o sistema crashar como um todo. entao acredito que o impacto na libc foi grande nesse caso. o lado bom eh que multiprocessamento ficou mais simples: o suporte a threads permite tanto multiplexar threads no mesmo processador, como rodar elas paralelamente em processadores diferentes. para isso, a libc foi forrada de semaforos e sistemas de sincronismo! se nao fosse isso, com certeza: maquinas SMP como o i5 nao estariam funcionando nada bem! hehehe
bom, nessa epoca surgiu tambem o projeto gnu e sua glibc. escrito do zero, adicionou bastante facilidades na libc e verificacoes, como checagem de ponteiros nulos. os caras do bsd, por outro lado, gracas ao openbsd, auditaram suas bibliotecas e reescreveram bastante coisa tambem. eh o que eu lembro assim de alteracoes drasticas na libc. mas se vc pegar o livro K&R de 1978, vai ver que as coisas sao mais ou menos as mesmas desde aquela epoca. entao a API mais geral nao mudou muito. ironicamente, a revolucao das interfaces graficas e mais tarde a web praticamente nao afetaram a libc: as aplicacoes simplesmente funcionam, usam a libc como parte essencial, mas a libc nao percebe diferenca alguma.
finalmente, nos ultimos anos eu tenho visto que o maior alvo eh o suporte a redes: o suporte original proposto pelo bsd estah bem obsoleto e novos mecanismos apareceram. obviamente, para a aplicacao falar com o kernel, eh essencial passar pela libc, mas ela tem segurado a performance quando as velocidades atingem os Gbps.
