Implementação do mecanismo WSS

Tempos atrás o Gian escreveu um post sobre como limitar sessões Progress usando o parâmetro –wss. No post de hoje pretendo explorar um pouco como funciona este mecanismo. A terminologia e as APIs apresentadas são exclusivas para Windows, visto que o client prowin32.exe só existe para este sistema operacional.

O mecanismo de limitação de sessões é implementado utilizando objetos do tipo semáforo. Um semáforo é um objeto de sincronização que permite limitar o número de threads que acessam um recurso compartilhado. Outros tipos de objetos de sincronização serviriam, mas a implementação atual do Progress utiliza semáforos.

Durante a inicialização, o Progress utiliza a API CreateSemaphore para criar/abrir um semáforo com o nome _PRO_WIN32_CLIENT_. Este semáforo sempre é criado/aberto, independente de ter sido utilizado ou não o parâmetro –wss. O Progress define uma variável interna indicando se um novo semáforo foi criado ou se já existia um semáforo com este nome.

Posteriormente, quando os parâmetros da sessão client forem processados, o Progress verifica se o parâmetro –wss foi utilizado. Caso positivo, a variável interna citada anteriormente é verificada. Se esta variável indicar que um novo semáforo foi criado, a sessão abre normalmente. Se a variável indicar que já existia um semáforo com o mesmo nome, o Progress conclui que já há uma sessão client aberta, tenta colocá-la em foco com a API SetForegroundWindow e fecha a sessão atual.

Quando vários usuários abrem sessões na mesma máquina através de recursos como Terminal Services, pode ser aberto no máximo um client Progress por sessão de usuário utilizando o parâmetro –wss. O gerenciador de objetos do Windows permite isolar alguns tipos de objetos (incluindo semáforos) por sessão de usuário e o Progress se utiliza deste recurso. Do contrário, apenas um único client poderia ser aberto por vez em uma máquina compartilhada por vários usuários.