
本文深入探讨了在 pyrogram 异步框架中集成同步或不当使用异步 `g4f` 库时常见的 `runtimeerror`,特别是关于任务与事件循环冲突的问题。通过分析同步和初步异步尝试中遇到的错误,明确指出解决方案是采用 `g4f` 库提供的异步 api `g4f.chatcompletion.create_async`,并结合 `await` 关键字,确保整个应用程序流程的非阻塞和异步兼容性。
在构建基于 Pyrogram 的 Telegram 用户机器人时,开发者常会遇到需要集成外部服务的情况,例如利用 g4f 库调用大型语言模型。然而,Pyrogram 是一个基于 asyncio 的异步框架,这意味着所有与其交互的代码都应遵循异步模式。当尝试将同步操作或不恰当的异步调用与 Pyrogram 的事件循环混合时,很容易引发 RuntimeError,导致程序崩溃。
最初的尝试可能是在 Pyrogram 的消息处理函数中直接调用 g4f.ChatCompletion.create。尽管 Pyrogram 的事件处理机制会尝试在单独的线程中运行同步回调,但当回调函数内部又试图执行异步操作(如 message.reply)时,便会发生事件循环冲突。
考虑以下同步代码示例:
import asyncio
from pyrogram import Client, filters
import g4f
app = Client("my_account")
@app.on_message(filters.text & filters.private)
def echo(client, message):
# g4f.ChatCompletion.create 是一个同步函数
result = g4f.ChatCompletion.create(
model="gpt-3.5-turbo",
provider=g4f.Provider.ChatBase,
messages=[{"role": "user", "content": message.text}],
stream=False
)
print(result)
# message.reply 是一个异步操作,但在同步函数中被 Pyrogram 封装为同步调用
message.reply(result)
app.run()运行上述代码时,可能会遇到类似如下的 RuntimeError:
RuntimeError: Task <Task pending name='Task-108' coro=<Message.reply_text() running at ...>> got Future <Future pending ...> attached to a different loop
这个错误表明,Pyrogram 尝试在后台线程中执行同步 echo 函数,但 echo 函数内部的 message.reply(result) 调用实际上是一个需要主事件循环执行的异步操作。pyrogram.sync.async_to_sync_wrap 会尝试将这个异步操作转换为同步,但由于 g4f.ChatCompletion.create 已经阻塞了当前线程,导致 message.reply 无法在正确的事件循环中被调度,从而引发“Future attached to a different loop”的错误。
面对上述错误,直观的解决方案是将消息处理函数声明为 async,并使用 await 关键字来等待异步操作。
import asyncio
from pyrogram import Client, filters
import g4f
app = Client("my_account")
@app.on_message(filters.text & filters.private)
async def echo(client, message):
# g4f.ChatCompletion.create 仍然是同步的
result = g4f.ChatCompletion.create(
model="gpt-3.5-turbo",
provider=g4f.Provider.ChatBase,
messages=[{"role": "user", "content": message.text}],
stream=False
)
print(result)
# await message.reply 是正确的异步调用方式
await message.reply(result)
app.run()然而,即便 echo 函数被声明为 async,g4f.ChatCompletion.create 本身仍然是一个同步函数。在异步函数中调用同步函数会阻塞整个事件循环,直到同步函数执行完毕。这可能导致 Pyrogram 的其他内部异步任务(如心跳、接收消息等)无法按时执行,从而引发新的 RuntimeError,例如:
RuntimeError: Cannot enter into task <Task pending name='Task-37' coro=<Dispatcher.handler_worker() running at ...>> while another task <Task pending name='Task-36' coro=<Dispatcher.handler_worker() running at ...>> is being executed.
这个错误表明,由于 g4f.ChatCompletion.create 的同步阻塞,Pyrogram 的事件循环被卡住,导致多个任务试图同时访问或修改相同的资源,或在不适当的时机切换上下文,从而破坏了 asyncio 的并发模型。
解决上述问题的关键在于,在异步环境中,所有可能阻塞 I/O 的操作都应该使用其对应的异步版本。幸运的是,g4f 库提供了 g4f.ChatCompletion.create_async 这个异步 API。
正确的做法是将 g4f.ChatCompletion.create 替换为 g4f.ChatCompletion.create_async,并在其前面加上 await 关键字,确保整个流程完全异步化。
import asyncio
from pyrogram import Client, filters
import g4f
app = Client("my_account")
@app.on_message(filters.text & filters.private)
async def echo(client, message):
# 使用 g4f.ChatCompletion.create_async 并 await 它
result = await g4f.ChatCompletion.create_async( # 注意这里的修改
model="gpt-3.5-turbo",
provider=g4f.Provider.ChatBase,
messages=[{"role": "user", "content": message.text}],
stream=False
)
print(result)
await message.reply(result)
app.run()在这个修正后的代码中:
通过这种方式,整个消息处理流程都保持了异步特性,避免了任何可能阻塞事件循环的同步调用,从而彻底解决了 RuntimeError。
通过遵循这些原则,开发者可以有效地在 Pyrogram 等异步框架中集成外部库,构建出高效、响应迅速且健壮的应用程序。
以上就是解决 Pyrogram 与 g4f 集成中的异步冲突:正确处理事件循环错误的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号