这位同学，首先无代码无真相。只能在这里猜测一下，你在GUI界面中点击了某个按钮，调用的函数然后触发了某种while循环，这个时候前台GUI将“未响应”卡死。不过一旦调用函数的while循环结束，GUI界面将再次可用。
不使用线程的话，后台while循环处理和前台GUI显示是依次串行的，做完一件事情才能做另一件。使用线程是GUI通常的做法，可以使后台while循环处理中的信息实时显示在前台GUI上。
关于tkiner的after方法，只是将函数的调用时间向后延时一些，进入调用的函数后与直接调用函数没有区别。
此外，根据题主说的request的事情，继续猜一下。首先来说下线程的事情，处理request的线程不能这样使用
p=Thread(target=a_while_func_about_request, args=(some_args))
p.start()
p.join()
这样使用线程虽然将主线程的while循环移到线程p的内部，但由于主线程一直等待p.join()什么也做不了，相当于主线程直接调用了a_while_func_about_request函数。要利用到线程的并发性能，主线程不能傻傻的p.join()，至少还需要一个标志变量，通过标志变量判断线程p是否完成request请求，例如：
# 主线程
request_done = False
p=Thread(target=a_while_func_about_request, args=(some_args))
p.start()
while request_done == False:
# 继续处理主线程逻辑
...
else:
# 根据request内容进行显示
...
p.join()
# 子线程部分
def a_while_func_about_request(some_args):
# request获取内容部分
...
request_done = True
2. GUI方面也需要根据程序逻辑设计：
情况一：在获取请求request内容的过程中GUI必须等待数据无法进行下一步操作，类似玩游戏时等待读进度条，无法跳过，GUI也无需提供其它操作。这种情况可以在等待期间显示一个“处理中...”的进度条，然后主线程定时检查request_done标志位（可以使用到after方法），等到request_done为True时，主程序知道request获取完毕，可以继续GUI后续的显示。
情况二：在获取request内容时，GUI继续显示某个主界面，稍后通过某个“读取结果”的按钮对结果进行显示，这样类似于游戏在读进度条的时候窗口切出去刷网页什么的，过一会儿再切回来看看进度条是否读好了。这种情况下，每次切回来看看进度条情况的相当于检查request_done标志位，根据是否完成设计GUI后续的显示流程。
)
