C#关于结束进程的问题

[tei333]

我创建一个线程，线程主要是获取一个从服务器获取的数据，但是服务器处理的时间很长，线程会一直卡在从服务器获取数据的地方，我现在想关掉这个线程，我知道可以用Abort这个方法强行结束进程，但是我看很多说法是这种方式不安全，我想请教一下这种情况还有其他的方法可以解决吗？

[weixin_40791311]

阻塞的方式获取服务器端的数据吗？

[tei333]

引用 1 楼 weixin_40791311 的回复:

阻塞的方式获取服务器端的数据吗？

单独开的一个线程获取数据，但是在这个线程里，它也会阻塞在获取服务端数据的指令上，这种方式的我不知道怎么结束进程好

[闭包客]

Abort 本身并没有问题，只要你的线程设计成被结束也不会造成逻辑错误的。 asp.net 的请求处理线程就是使用 Abort 结束的。

[白衣如花]

后台线程 或者设置一个flag，关闭程序设置flag为false，线程检测到flag为false，不再执行

[tei333]

引用 4 楼 u012948520 的回复:

后台线程 或者设置一个flag，关闭程序设置flag为false，线程检测到flag为false，不再执行

关键就是一直卡在从服务端获取数据那里，根本不会去循环检查标志位

[tei333]

引用 3 楼 closurer 的回复:

Abort 本身并没有问题，只要你的线程设计成被结束也不会造成逻辑错误的。 asp.net 的请求处理线程就是使用 Abort 结束的。

这个应该不会造成逻辑错误，我只是需要从服务端获取数据，有数据返回就显示，我用abort结束进程，再把这个结束方法放在try里，是不是就不会引发其他什么问题了？这样就安全了吗？

[白衣如花]

引用 5 楼 tei333 的回复:

[quote=引用 4 楼 u012948520 的回复:] 后台线程 或者设置一个flag，关闭程序设置flag为false，线程检测到flag为false，不再执行

关键就是一直卡在从服务端获取数据那里，根本不会去循环检查标志位[/quote]一般有个timeout的设置吧？超过一段时间不返回就认为异常了。 如果是双向通讯，就不用阻塞式申请数据。每次调用都带一个ID，服务端处理完主动推送把ID和结果传回来就好了。

[郑州高新区WPF小王子]

用Task任务，它是由线程池线程执行，线程池线程由线程池创建，管理，销毁，不需要手动释放。

[tei333]

引用 8 楼 duanzi_peng 的回复:

用Task任务，它是由线程池线程执行，线程池线程由线程池创建，管理，销毁，不需要手动释放。

task任务的取消是用cancellationtokensource的cancel方法取消，它也是在任务里通过循环检查cancellationtoken.iscancellationrequested的方式来确认是否结束的。原理上和循环检查一个标志位是一样的，现在进程阻塞的原因是因为堵在服务端获取数据这一条指令上，在没有获取到数据之前不会去检查标志位的。我也不清楚task是否还有其他结束进程的方式~

[郑州高新区WPF小王子]

引用 9 楼 tei333 的回复:

[quote=引用 8 楼 duanzi_peng 的回复:] 用Task任务，它是由线程池线程执行，线程池线程由线程池创建，管理，销毁，不需要手动释放。

task任务的取消是用cancellationtokensource的cancel方法取消，它也是在任务里通过循环检查cancellationtoken.iscancellationrequested的方式来确认是否结束的。原理上和循环检查一个标志位是一样的，现在进程阻塞的原因是因为堵在服务端获取数据这一条指令上，在没有获取到数据之前不会去检查标志位的。我也不清楚task是否还有其他结束进程的方式~[/quote] 从服务端获取数据的线程阻塞了吧，阻塞导致程序不继续运行直到有数据返回，这个需要用异步来处理了，异步处理不需要等待，直到它的回调函数执行，来处理从服务端返回的数据。

[闭包客]

引用 6 楼 tei333 的回复:

[quote=引用 3 楼 closurer 的回复:] Abort 本身并没有问题，只要你的线程设计成被结束也不会造成逻辑错误的。 asp.net 的请求处理线程就是使用 Abort 结束的。

这个应该不会造成逻辑错误，我只是需要从服务端获取数据，有数据返回就显示，我用abort结束进程，再把这个结束方法放在try里，是不是就不会引发其他什么问题了？这样就安全了吗？[/quote] abort 本身是没有问题的，你要想的是 abort 的时候，数据下载到一半怎么办，保存到一半怎么办，显示到一半怎么办……