Bem, isso depende da definição. Sistemas diferentes podem ter costumes diferentes ou nomes diferentes para a mesma coisa.
A definição POSIX é que um processo é identificado por um espaço de endereço (memória visível para o processo) e que muitos / a maioria dos recursos do sistema operacional pertencem ao processo. (ID do processo (obviamente), IDs do usuário, diretório de trabalho, descritores de arquivos ...)
Por outro lado, um segmento é definido como um "fluxo de controle "dentro de um processo, incluindo o ambiente de tempo de execução (registradores da CPU, status de ponto flutuante), e por exemplo a prioridade de agendamento.
Normalmente, processamos < - > recursos, thread < - > agendamento.
Mas não precisa ser exatamente assim. No Linux, os recursos compartilhados por um processo e seu filho podem ser definidos pela clone(2) chamada do sistema , pelo menos parece possível ter dois processos que compartilham descritores de arquivos, mas possuem espaços de endereço distintos. Ou o contrário.
Além disso, nos tempos passados, o Linux não tinha uma distinção adequada entre processos e threads, havia apenas processos no nível do kernel. (Tecnicamente, a coisa que geralmente consideramos um thread ainda é chamada de "processo" pelo kernel, e um processo no sentido usual é chamado de "grupo de processos").
Alguns tipos de encadeamentos podem ser implementados apenas no espaço do usuário, sem suporte do sistema operacional. Nesse caso, os encadeamentos não seriam planejados pelo mesmo sistema que os processos, já que o planejador do SO nem saberia que eles existem. Mas, mesmo nesse caso, a implementação do espaço do usuário precisaria ter alguma maneira de determinar qual encadeamento deve ser executado. (As implementações de threads no espaço do usuário são obsoletas em sistemas que implementam threads adequados, mas essa é a única situação em que consigo pensar que está perto do seu terceiro ponto.)