Processstartinfo waitforexit trava

Processstartinfo waitforexit trava
Obter através da App Store Leia esta publicação em nosso aplicativo!
Process. WaitForExit doesn & # 39; t retornam mesmo que Process. HasExited seja verdade.
Eu uso Process. Start para iniciar um arquivo em lote. O arquivo em lote usa o comando "INICIAR" para iniciar vários programas em paralelo e depois sai.
Uma vez que o arquivo em lote é feito Process. HasExited torna-se verdadeiro e Process. ExitCode contém o código de saída correto.
Mas quando chamo Process. WaitForExit (), ele trava / nunca retorna.
O código a seguir demonstra o problema. Ele cria um arquivo em lotes, o inicia e depois imprime:
Ele deve imprimir:
. mas nunca faz (mesmo que HasExited é verdadeiro e já temos um ExitCode).
Percebi que isso só ocorre quando o arquivo em lotes contém comandos "INICIAR" e quando a saída padrão e / ou o erro padrão são redirecionados.
Por que WaitForExit () nunca retorna?
Qual é o caminho certo para esperar que esse processo saia?
É seguro apenas pesquisar Process. HasExited ou isso pode resultar em outros problemas?
PS .: Eu notei que chamar WaitForExit (100000) com um tempo limite enorme (que definitivamente não expira) retorna imediatamente quando o processo sai. Wierd. Sem tempo limite, trava.
Isso parece ser um artefato (eu diria "bug") na implementação específica do tratamento assíncrono baseado em eventos do StandardOutput e do StandardError.
Percebi que, enquanto consegui reproduzir facilmente o seu problema, simplesmente executando o código que você forneceu (excelente exemplo de código, a propósito! :)), o processo realmente não foi suspenso indefinidamente. Em vez disso, ele retornou de WaitForExit () uma vez que ambos os processos filho que tinham sido iniciados já haviam saído.
Esta parece ser uma parte intencional da implementação da classe Process. Em particular, no método Process. WaitForExit (), uma vez que acabou de aguardar o processo, ele verifica se um leitor para stdout ou stderr foi criado; se assim for, e se o valor de tempo limite para a chamada WaitForExit () for "infinito" (ou seja, -1), o código realmente espera o fim do fluxo no (s) leitor (es).
Cada leitor respectivo é criado somente quando o método BeginOutputReadLine () ou BeginErrorReadLine () é chamado. Os fluxos stdout e stderr não estão fechados até que os processos filho tenham fechado. Então, esperando no final desses fluxos irá bloquear até que isso aconteça.
Que WaitForExit () deve se comportar de forma diferente, dependendo se um tenha chamado qualquer um dos métodos que iniciam a leitura baseada em eventos dos fluxos ou não, e especialmente porque a leitura desses fluxos diretamente não faz WaitForExit () se comportar desse jeito, cria uma inconsistência na API que torna muito mais difícil de entender e usar. Enquanto eu pessoalmente chamaria isso de bug, suponho que seja possível que o (s) implementador (es) da classe Process esteja ciente dessa inconsistência e criou de propósito.
Em qualquer caso, o trabalho seria ler StandardOutput e StandardError diretamente em vez de usar a parte baseada em eventos da API. (Embora, é claro, se o código de alguém aguardasse esses fluxos, verificaria o mesmo comportamento de bloqueio até que o filho fique próximo).
Por exemplo (C #, porque eu não sei F # bem o suficiente para tapar um exemplo de código como este juntos rapidamente :)):
Felizmente, o trabalho acima ou algo semelhante abordará o problema básico que você encontrou. Meus agradecimentos ao comentarista Niels Vorgaard Christensen por dirigir-me para as linhas problemáticas no método WaitForExit (), para que eu possa melhorar essa resposta.

Code Ducky.
um blog para codificadores por codificadores.
Trabalhando com processos em.
Os idiomas de scripts e shell são geralmente construídos em torno da capacidade de um processo para iniciar facilmente e trabalhar com os resultados dos outros. Este é o principal modo de processamento em bash, enquanto o ruby ​​suporta pelo menos 5 abordagens integradas com diferentes níveis de flexibilidade e concisão.
Em, isso é uma espécie de operação normalmente é feito através da API System. Diagnostics. Process. O Process API é bastante geral e poderoso, mas pode ser complicado e difícil de usar corretamente nos casos de uso comum que são tratados tão bem pelas linguagens acima. Como um spoiler, acabei envolvendo grande parte dessa complexidade em uma nova biblioteca: MedallionShell. Com o MedallionShell, esse tipo de tarefa é um one-liner:
Mais sobre isso mais tarde, no entanto. Por enquanto, vamos voltar ao Processo. Como um exemplo concreto, recentemente queria que meu aplicativo lancasse uma instância do NodeJS para executar o compilador menos css. Eu precisava escrever na entrada padrão do Node & # 8217; ao capturar o texto de saída padrão, texto de erro padrão e código de saída.
Uma tentativa inicial.
Aqui é o código com que comecei:
Este código é bastante detalhado; infelizmente também é bastante buggy.
Lidando com os argumentos do processo.
Um dos primeiros problemas que notamos com este código é que a propriedade Arguments no ProcessStartInfo é apenas uma string. Se os argumentos que estamos passando são dinâmicos, precisaremos fornecer a lógica de escape adequada antes de concatenar para impedir que coisas como espaços em caminhos de arquivos sejam quebrados. Escapar os argumentos da linha de comando do Windows é estranhamente complexo; Felizmente, o código necessário para implementá-lo está bem documentado nesta publicação do StackOverflow. Assim, a primeira mudança que nós vamos fazer é adicionar lógica de escape:
Lidar com deadlocks.
Um problema menos óbvio é o bloqueio. Os três fluxos de processo (entrada, saída e erro) são finitos em quanto de conteúdo eles podem armazenar. Se o buffer interno for preenchido, então quem estiver escrevendo para o fluxo irá bloquear. Neste código, por exemplo, não lemos os fluxos de saída e erro até que o processo tenha saído. Isso significa que podemos encontrar-nos em um caso em que o Node esgota o buffer de erro. Nesse caso, o Nó bloquearia a gravação em erro padrão, enquanto nosso aplicativo está bloqueado a leitura até o final do padrão. Assim, nós nos encontramos em um impasse!
O Process API fornece um método que parece projetado para lidar com isso: BeginOutput / ErrorReadLine. Com este método, você pode assinar o assíncrono & # 8220; DataReceived & # 8221; eventos em vez de ler os fluxos de saída diretamente. Dessa forma, você pode ouvir ambos os fluxos ao mesmo tempo. Infelizmente, este método não fornece nenhuma maneira de saber quando o último bit de dados foi recebido. Porque tudo é assíncrono, é possível (e eu observei isso) para que os eventos disparem depois que WaitForExit () retornou.
Felizmente, podemos fornecer nossa própria solução alternativa usando Tarefas para ler asíncronamente as transmissões enquanto aguardamos o Nó para sair:
Adicionando um tempo limite.
Outra questão que gostaria de lidar é a de um processo pendurado. Em vez de esperar para que o processo saia, nosso código seria mais robusto se forçássemos um timeout em vez disso:
Async todo o caminho!
Enquanto nós agora estamos usando o IO assíncrono para ler dos fluxos do processo, ainda estamos bloqueando um segmento enquanto aguardamos o processo para concluir. Podemos melhorar a eficiência aqui, indo totalmente assíncrono:
Adaptando-se a volumes de dados maiores.
Outra questão que pode surgir ao tentar generalizar essa abordagem é a do volume de dados. Se estivermos fornecendo uma grande quantidade de dados através do processo, nós provavelmente queremos substituir as chamadas convenientes ReadToEndAsync () com loops de leitura assíncronos que processam cada pedaço de dados conforme ele vem.
Mudando para MedallionShell.
Nós já construímos um código (esperançosamente) correto, robusto e eficiente para trabalhar com um processo. No entanto, espero que este exemplo o tenha convencido de que a API do Processo não é suficiente para o trabalho quando se trata de facilidade de uso. Para esse fim, irei apresentar uma alternativa: a biblioteca MedallionShell (disponível no NuGet). Aqui, a lógica equivalente usando MedallionShell:
Com o MedallionShell, os argumentos são escapados automaticamente, os fluxos de processo são automaticamente armazenados em buffer para evitar o impasse, e tudo está bem envolvido em uma API baseada em tarefas compatível com asínc. Nós não teremos que nos preocupar em chamar Dispose (): por padrão, o Processo é descartado automaticamente após a conclusão do comando.
O MedallionShell também oferece sobrecargas do operador para permitir o redirecionamento semelhante à da entrada padrão e saída padrão. Isso significa que você pode usar & # 8220; & lt; & # 8221; e & # 8220;> & # 8221; para canalizar dados de e para fluxos, arquivos e coleções. Você pode até usar o & # 8220; | & # 8221; para canalizar dados de um objeto Command para outro.
Mike Adelson.
Últimas publicações de Mike Adelson (ver todos)
Implementando Equals () e GetHashCode () em C # 7 - 3 de junho de 2017 Scripting in C # - 3 de maio de 2017 7 maneiras de usar C # 7 throw expressions - 26 de abril de 2017.
Sobre Mike Adelson.
I & # 8217; m engenheiro de software em Applied Predictive Technologies em Washington D. C., onde trabalho em & # 8220; dados grandes & # 8221; análise e desenvolvimento web. No meu tempo livre, eu gosto de ler, trabalhar em vários projetos paralelos e responder perguntas no StackOverflow.
Pós-navegação.
7 pensamentos sobre & ldquo; Trabalhando com processos em & rdquo;
É possível ler e escrever para o mesmo processo dentro do mesmo programa. Eu usei o shell medalhão para ler a saída de um programa de console interativo. Mas quando eu iniciar um segmento diferente para escrever comandos para o programa, o writestream. writeline parece apenas pendurar. Estou tentando controlar pianobar (veja github). Há algum passo ao tentar ler uma linha do processo e responder com uma linha. Isto está me enlouquecendo.
Sim, deve ser possível ler e escrever para um processo dentro do mesmo programa. Certifique-se de que está usando a versão mais recente do MedallionShell e que a entrada padrão do comando está definida como AutoFlush (deve ser o padrão).
Você pode observar WriteLine para pendurar se o processo de destino não for puxar os dados e o buffer interprocesso for preenchido (evitando assim que o preenchimento seja concluído).
É difícil para mim dizer mais sem ver o seu código; considere postar uma descrição mais detalhada e uma amostra de código como um problema em https: // github / madelson / MedallionShell.
Obrigado Michael. Eu fiz exatamente isso, o problema # 9 #. Liguei a minha pergunta. Claramente, eu estava com muito sono para escrever qualquer coisa. Eu quis dizer que há algum passo que é necessário que eu esteja faltando. Algo óbvio para todos os outros por mim.
É possível aguardar uma string específica no fluxo de saída do comando?
bool found = await cmd. StandardOutput. Expect (searchstring, timeout);
Não há funcionalidades incorporadas para fazer isso. Se a string não abranger uma linha, você poderia fazer:
enquanto ((linha = cmd. StandardOutput. ReadLine ())! = null)
Se a cadeia de pesquisa abranger várias linhas, você pode usar uma técnica de loop semelhante, onde você acompanha os últimos N caracteres onde N é o comprimento da seqüência de pesquisa.

Exemplo de uso.
Resolvi assim:
Eu redirecionava a entrada, a saída e o erro e administrai a leitura dos fluxos de saída e erro. Esta solução funciona para o SDK 7- 8.1, tanto para o Windows 7 como para o Windows 8.
Eu tentei fazer uma aula que resolva seu problema usando a leitura de fluxo assíncrono, levando em conta Mark Byers, Rob, Stevejay responde. Ao fazê-lo, percebi que existe um erro relacionado à leitura assíncrona do fluxo de saída do processo.
Você não pode fazer isso:
Você receberá System. InvalidOperationException: StandardOut não foi redirecionado ou o processo ainda não começou.
Então, você deve iniciar a saída assíncrona lida após o processo ser iniciado:
Fazendo isso, faça uma condição de corrida porque o fluxo de saída pode receber dados antes de configurá-lo como assíncrono:
Então algumas pessoas podem dizer que você só precisa ler o fluxo antes de configurá-lo como assíncrono. Mas o mesmo problema ocorre. Haverá uma condição de corrida entre a leitura síncrona e configurará o fluxo em modo assíncrono.
Não há como conseguir uma leitura assíncrona segura de um fluxo de saída de um processo na forma real "Processo" e "ProcessStartInfo" foi projetado.
Você provavelmente está melhor usando a leitura assíncrona, como sugerido por outros usuários para o seu caso. Mas você deve estar ciente de que você pode perder algumas informações devido à condição de corrida.
Nenhuma das respostas acima está fazendo o trabalho.
A solução Rob trava e a solução 'Mark Byers' obtém a exceção descarta. (Eu tentei as "soluções" das outras respostas).
Então eu decidi sugerir outra solução:
Este código é depurado e funciona perfeitamente.
Eu acho que isso é uma abordagem simples e melhor (não precisamos do AutoResetEvent):
Eu estava tendo o mesmo problema, mas a razão era diferente. No entanto, isso aconteceria no Windows 8, mas não no Windows 7. A seguinte linha parece ter causado o problema.
A solução era NÃO desativar UseShellExecute. Agora recebi uma janela popup do Shell, que é indesejável, mas muito melhor do que o programa esperando que nada de particular aconteça. Então eu adicionei o seguinte trabalho para isso:
Agora, o único problema que me incomoda é o porquê isso está acontecendo no Windows 8, em primeiro lugar.
Introdução.
A resposta atualmente aceita não funciona (lança exceção) e há muitas soluções alternativas, mas nenhum código completo. Isso é, obviamente, desperdiçando muito tempo das pessoas porque esta é uma questão popular.
Combinando a resposta de Mark Byers e a resposta de Karol Tyl, escrevi um código completo baseado em como eu quero usar o método Process. Start.
Eu usei-o para criar um diálogo de progresso em torno dos comandos git. É assim que eu usei isso:
Em teoria, você também pode combinar stdout e stderr, mas não testei isso.
Eu sei que isso é velho, mas, depois de ler toda essa página, nenhuma das soluções estava funcionando para mim, embora eu não tentei Muhammad Rehan porque o código era um pouco difícil de seguir, embora eu acho que ele estava no caminho certo . Quando eu digo que não funcionou, isso não é inteiramente verdade, às vezes funcionaria bem, acho que é algo a ver com a duração da saída antes de uma marca EOF.
De qualquer forma, a solução que funcionou para mim era usar diferentes threads para ler o StandardOutput e StandardError e escrever as mensagens.
Espero que isso ajude alguém, que pensou que isso poderia ser tão difícil!
As outras soluções (incluindo o EM0) ainda estão bloqueadas para o meu aplicativo, devido a tempos de espera internos e ao uso de StandardOutput e StandardError pela aplicação gerada. Aqui está o que funcionou para mim:
Editar: inicialização adicionada de StartInfo para codificar a amostra.
Este post talvez esteja desactualizado, mas descobri a principal causa por que normalmente ele trava é devido ao excesso de pilha para o redirectStandardoutput ou se você tem redirectStandarderror.
Como os dados de saída ou os dados de erro são grandes, isso causará um tempo de espera, pois ele ainda está processando por tempo indefinido.

Первичная навигация.
Форум только для чтения.
Администраторы сделали этот форум доступным только для чтения. Новые беседы или комментарии не могут быть добавлены.
Processe hnags ao executar qualquer comando usando o & # 160; Process. Start ()
Porque se o Process. Start () for bem-sucedido, eu poderia começar a interrogar a saída.
O ManagementBaseObject retornado pelo InvokeMethod não contém o retorno de saída real pelo processo.
Eu acho que isso pode estar relacionado com o redirecionamento de saída / erro. Isso é feito de maneira sinônimo, então você não pode redirecionar os dois ao mesmo tempo. Para fazer isso, ele deve ser feito de forma assíncrona. (BeginOutputReadLine, BeginErrorReadLine)
& quot; O exemplo de código evita a condição de bloqueio executando operações de leitura assíncronas no fluxo StandardOutput. Um estado de impasse resulta se o processo pai chamar p. StandardOutput. ReadToEnd seguido de p. StandardError. ReadToEnd e o processo filho escreve texto suficiente para preencher o fluxo de erros. O processo pai aguardaria indefinidamente o processo filho para fechar o fluxo StandardOutput. O processo infantil esperaria indefinidamente para o pai ler o fluxo completo do StandardError.
Você pode usar operações de leitura assíncronas para evitar essas dependências e seu potencial de impasse. Alternativamente, você pode evitar a condição de bloqueio criando dois segmentos e lendo a saída de cada fluxo em um segmento separado. & Quot;
URL em VS2005 Documentação:
Você já descobriu esse problema? Estou inclinado a pensar que é um bug no material de personificação em 2.0. Se eu remover a representação, isso funciona bem. mesmo a re-direção da saída e erro. Mas no momento que você tenta executar o processo como outro usuário, o processo é iniciado, mas depois trava. Eu diria segurança, exceto que não existe um erro por si. O processo começa bem, mas depois trava. Se fosse segurança, pensaria que você nunca começaria o processo. Também é interessante porque o problema também entra em cascata através dos processos. Por exemplo, eu tentei envolver minha chamada de personificação em outro exe para que eu pudesse iniciar o programa inicial (do ASP) sem nenhuma representação. A mesma coisa acontece; o processo trava. não o processo de invólucro. O processo dentro do invólucro que está sendo representado trava! Louco. Se você executar o wrapper exe como qualquer usuário, ele também funciona bem, então eu sei que o wrapper funciona em todos os contextos que não sejam asp.
Alguém encontrou a solução para este problema?
Aqui está um que funciona no modo de depuração no ASP (2.xxx),
mas não funciona no modo publicado: ajuda!
classe pública myClass.
string público strBalance = string. Empty;
string privado runProc (string args)
Process proc = new Process ();
string passwordPre = & quot; MyPassword & quot ;;
char [] passwordChars = passwordPre. ToCharArray ();
SecureString password = new SecureString ();
foreach (char c in passwordChars)
return strBalance; // Eu nunca chego aqui publicado, eu trabalho em depuração.
strBalance & # 43; = e. Data; // Eu nunca chegar aqui em publicado, eu trabalho em depuração.
Беседа заблокирована.
Администраторы заблокировали эту беседу. Новые комментарии не могут быть добавлены.
© Майкрософт (Microsoft), 2018. Корпорация Microsoft сохраняет за собой все права, связанные с материалами на этом сайте.

Command. StandardOutput. ReadToEnd () trava cada vez que # 12.
xjfnet comentou 3 de junho de 2017.
adb. exe is is Android Debug Bridge.
O snippet de código trava sempre com as opções 1.0.31 do adb. exe. O Timeout não funciona, o processo de sublinhado que ainda está sendo executado após 1 minuto, o snippet de código funciona bem com a versão adb. exe 1.0.39.
madelson comentou 3 de junho de 2017.
Oi @xjfnet. Eu tenho algumas perguntas:
Qual versão do MedallionShell você está executando? Qual sistema operacional e plataforma (por exemplo, Framework 4.5, Core 1.0, Mono, etc.) você está usando? Quando você diz que ele trava cada vez, em que linha está pendurado? O que acontece quando você faz:
xjfnet comentou 4 de junho de 2017.
MedallionShell 1.3.0 Win10, NET Framework 4.5.2 command. StandardOutput. ReadToEnd () comando. Result. StandardOutput trava.
madelson comentou 4 de junho de 2017 e # 8226;
@xjfnet interessante e obrigado pelos detalhes adicionais. Com base no que escreveu, parece que o AdB está saindo normalmente; command. Result não retornará até o processo ter saído.
Isso sugere para mim que a saída está sendo presa no tubo de alguma forma, de modo que o fluxo de saída não esteja se fechando corretamente.
Como eu não tenho essa exe particular em execução na minha máquina, depurar isso será complicado. Mais algumas coisas que ajudariam:
Qual é o código de saída que você obtém result. ExitCode? Qual é o resultado que você espera do adb. exe? Se você lê pela primeira vez um erro padrão, você vê alguma coisa lá? Em vez de chamar ReadToEnd (), o que você vê se você lê um personagem de cada vez: mais uma coisa a tentar seria simplesmente iniciar o processo diretamente com a API subjacente:
xjfnet comentou 4 de junho de 2017.
porque está pendurado, então não consigo obter ExitCode a saída do adb. exe assim, se eu ler o erro padrão primeiro, não a saída padrão, ele trava o código do seu código e, em seguida, obtenho toda a saída correta, mas ainda trava, pode 't sair.
madelson comentou 4 de junho de 2017.
@xjfnet para # 1, você não pode puxar resultado. ExitCode antes de obter o resultado?
xjfnet comentou 4 de junho de 2017 e # 8226;
Não consigo puxar ExitCode, ele trava ao ler comando. Result. ExitCode.
mas execute adb. exe no prompt de comando, o errorlevel é 0.
Para testar esta questão, você só precisa da versão 1.0.31 adb. exe, "127.0.0.1:21503" pode ser qualquer coisa.
exemplo: adb connect xxx.
madelson comentou 4 de junho de 2017.
@xjfnet muito interessante. Se eu estiver lendo suas respostas corretamente, command. Result retornou quando executando # 4 do meu primeiro conjunto de perguntas (porque o bloqueio estava na linha StandardOutput), mas quando você executou o código revisado com o comando ExitCode. O Rechultado não estava retornando. Isso esta certo?
Você pode me apontar para onde eu posso baixar a versão adb. exe específica necessária para reproduzir isso?
xjfnet comentou 4 de junho de 2017 e # 8226;
Eu busco "adb 1.0.31 zip" com o bing, e obtenha este https://hostr. co/bBxxj7gFfMlW.
Executo o código com este adb. exe, ele pode reprovar esse problema.
importante: para reprovar esta questão matar adb. exe primeiro é necessário.
xjfnet comentou 4 de junho de 2017 e # 8226;
linha 16. WaitForExit () está concluída.
madelson comentou 4 de junho de 2017.
Oi @xjfnet eu criei um pouco mais e replicou seu problema. Ainda não tenho uma solução, mas estou começando a entender o que está acontecendo um pouco mais:
Primeiro, quando o adb. exe é executado, ele cria um processo em segundo plano que também é adb. exe se não houver um já. Esse processo continua funcionando mesmo após o adb. exe morrer. É por isso que parece que o tempo limite não está matando o processo (é).
Em segundo lugar, se você executar o adb. exe quando o processo de fundo já existe, tudo funciona bem e você pode obter o texto do padrão. O processo existe normalmente.
No entanto, no primeiro caso em que o processo em segundo plano é criado, acontece algo estranho. Basicamente, o processo principal não vai sair e mesmo quando o fluxo de saída padrão não fecha. Em todos os casos, já vi anteriormente, os fluxos de IO padrão morrem imediatamente após a saída do processo.
Este é, em última análise, o que causa o comportamento suspenso. MedallionShell não deixará Command. Result retornar até que o processo tenha saído e todos os bytes dos fluxos de saída tenham sido armazenados em buffer ou consumidos (geralmente um recurso útil). Neste caso, uma vez que a saída padrão nunca fecha, o IO nunca é visto como sendo concluído e a coisa toda é suspensa.
Neste ponto, não sinto que posso implementar uma solução até entender o que está acontecendo sob o capô um pouco melhor. Eu fiz uma pergunta sobre StackOverflow (https: // stackoverflow / questions / 44358255 / standardoutput-stream-stay-open-after-process-exits) que inclui uma reprodução autônoma do comportamento estranho.
Enquanto isso, uma solução para o seu caso de uso pode ser simplesmente executar o adb. exe duas vezes. Na primeira vez, use a opção StartInfo para desativar o redirecionamento para todos os fluxos. Essa execução assegurará que o daemon seja criado. Em seguida, execute novamente novamente.
xjfnet comentou 5 de junho de 2017.
Os códigos abaixo podem ser executados até o final sem pendurar.
O resultado do programa com adb versão 1.0.31 é:
e o resultado com adb versão 1.0.39 é:
talvez haja algum erro na versão adb. exe 1.0.31, o final do stdout / sdterr não pode ser alcançado.
madelson comentou 5 de junho de 2017.
@xjfnet sim, a versão mais antiga desse processo definitivamente se comporta estranhamente. Estou muito curioso para saber o que exatamente está fazendo sob o capô que causa esse comportamento.
madelson comentou 1 de julho de 2017 e # 8226;
@xjfnet Eu olhei para isso um pouco mais. Pelo que posso dizer, não há realmente o código para desanexar-se com segurança deste processo específico. Como os tubos abertos a partir do processo são síncronos, não assíncronos, o cancelamento não funciona. Eu até tentei fechar manualmente o identificador do arquivo: isso nem sequer quebra a leitura.
Isso significa que, mesmo que forçássemos uma saída através de um mecanismo de cancelamento em camadas, teríamos um vazamento de memória devido à tarefa subjacente que nunca foi concluída. Isso, por sua vez, significa que esta "solução" acaba sendo equivalente a você chamando Command. Task. Wait (CancelamentoToken) em seu código para evitar pendurar (o que funcionaria hoje).
Como este é o único processo em que eu vi isso; Eu vou fechar isso e deixar o código como é por enquanto. Eu vou revisitar se mais instâncias de tais processos estão causando problemas para as pessoas, se tropeçaremos com uma solução robusta para esse problema.
Obrigado pela sua ajuda na investigação. É um problema muito interessante.
Compucorss comentou 19 de dezembro de 2017.
Eu sei que isso está fechado, mas eu tive um tempo esta semana lutando com ReadToEnd () que pendurou por cinco ou mais minutos. Acontece que minha solicitação HttpRequest precisava de uma solicitação. Proxy = null; Depois disso, funcionou como um encanto. Esperando que ajude alguém.
madelson comentou 19 de dezembro de 2017.
@compucorss Não tenho a certeza de seguir o seu cenário. O HttpRequest foi feito sem a configuração do proxy no processo externo? Qual foi a conexão ao StandardOut? Em geral, ReadToEnd () não pode retornar até o processo externo fechar o StandardOut ou, mais provavelmente, as saídas. Portanto, qualquer coisa que cause o processo externo para pendurar (por exemplo, um loop infinito, deadlock, etc.) fará com que o ReadToEnd () seja suspenso.
Compucorss comentou 19 de dezembro de 2017.
Desculpe, eu deveria ter mencionado que não tinha nada a ver com o código acima. Estava apenas comentando sobre um problema separado que eu tinha. Não consegui acessar a máquina agora, mas eu estava trabalhando em uma instalação local tentando chamar uma API GET de um fornecedor. Eu publicarei o código se você estiver interessado mais tarde. Obrigado!
&cópia de; 2018 GitHub, Inc. Termos Privacidade Segurança Status Ajuda.
Você não pode executar essa ação neste momento.
Você fez login com outra guia ou janela. Recarregue para atualizar sua sessão. Você se separou em outra guia ou janela. Recarregue para atualizar sua sessão.