ai_v/venv/Lib/site-packages/greenlet/TThreadStateDestroy.cpp
24024 af7c11d7f9 feat(api): 实现图像生成及后台同步功能
- 新增图像生成接口,支持试用、积分和自定义API Key模式
- 实现生成图片结果异步上传至MinIO存储,带重试机制
- 优化积分预扣除和异常退还逻辑,保障用户积分准确
- 添加获取生成历史记录接口,支持时间范围和分页
- 提供本地字典配置接口,支持模型、比例、提示模板和尺寸
- 实现图片批量上传接口,支持S3兼容对象存储

feat(admin): 增加管理员角色管理与权限分配接口

- 实现角色列表查询、角色创建、更新及删除功能
- 增加权限列表查询接口
- 实现用户角色分配接口,便于统一管理用户权限
- 增加系统字典增删查改接口,支持分类过滤和排序
- 权限控制全面覆盖管理接口,保证安全访问

feat(auth): 完善用户登录注册及权限相关接口与页面

- 实现手机号验证码发送及校验功能,保障注册安全
- 支持手机号注册、登录及退出接口,集成日志记录
- 增加修改密码功能,验证原密码后更新
- 提供动态导航菜单接口,基于权限展示不同菜单
- 实现管理界面路由及日志、角色、字典管理页面访问权限控制
- 添加系统日志查询接口,支持关键词和等级筛选

feat(app): 初始化Flask应用并配置蓝图与数据库

- 创建应用程序工厂,加载配置,初始化数据库和Redis客户端
- 注册认证、API及管理员蓝图,整合路由
- 根路由渲染主页模板
- 应用上下文中自动创建数据库表,保证运行环境准备完毕

feat(database): 提供数据库创建与迁移支持脚本

- 新增数据库创建脚本,支持自动检测是否已存在
- 添加数据库表初始化脚本,支持创建和删除所有表
- 实现RBAC权限初始化,包含基础权限和角色创建
- 新增字段手动修复脚本,添加用户API Key和积分字段
- 强制迁移脚本支持清理连接和修复表结构,初始化默认数据及角色分配

feat(config): 新增系统配置参数

- 配置数据库、Redis、Session和MinIO相关参数
- 添加AI接口地址及试用Key配置
- 集成阿里云短信服务配置及开发模式相关参数

feat(extensions): 初始化数据库、Redis和MinIO客户端

- 创建全局SQLAlchemy数据库实例和Redis客户端
- 配置基于boto3的MinIO兼容S3客户端

chore(logs): 添加示例系统日志文件

- 记录用户请求、验证码发送成功与失败的日志信息
2026-01-12 00:53:31 +08:00

224 lines
8.2 KiB
C++

/* -*- indent-tabs-mode: nil; tab-width: 4; -*- */
/**
* Implementation of the ThreadState destructors.
*
* Format with:
* clang-format -i --style=file src/greenlet/greenlet.c
*
*
* Fix missing braces with:
* clang-tidy src/greenlet/greenlet.c -fix -checks="readability-braces-around-statements"
*/
#ifndef T_THREADSTATE_DESTROY
#define T_THREADSTATE_DESTROY
#include "TGreenlet.hpp"
#include "greenlet_thread_support.hpp"
#include "greenlet_compiler_compat.hpp"
#include "TGreenletGlobals.cpp"
#include "TThreadState.hpp"
#include "TThreadStateCreator.hpp"
namespace greenlet {
extern "C" {
struct ThreadState_DestroyNoGIL
{
/**
This function uses the same lock that the PendingCallback does
*/
static void
MarkGreenletDeadAndQueueCleanup(ThreadState* const state)
{
#if GREENLET_BROKEN_THREAD_LOCAL_CLEANUP_JUST_LEAK
// One rare platform.
return;
#endif
// We are *NOT* holding the GIL. Our thread is in the middle
// of its death throes and the Python thread state is already
// gone so we can't use most Python APIs. One that is safe is
// ``Py_AddPendingCall``, unless the interpreter itself has
// been torn down. There is a limited number of calls that can
// be queued: 32 (NPENDINGCALLS) in CPython 3.10, so we
// coalesce these calls using our own queue.
if (!MarkGreenletDeadIfNeeded(state)) {
// No state, or no greenlet
return;
}
// XXX: Because we don't have the GIL, this is a race condition.
if (!PyInterpreterState_Head()) {
// We have to leak the thread state, if the
// interpreter has shut down when we're getting
// deallocated, we can't run the cleanup code that
// deleting it would imply.
return;
}
AddToCleanupQueue(state);
}
private:
// If the state has an allocated main greenlet:
// - mark the greenlet as dead by disassociating it from the state;
// - return 1
// Otherwise, return 0.
static bool
MarkGreenletDeadIfNeeded(ThreadState* const state)
{
if (!state) {
return false;
}
LockGuard cleanup_lock(*mod_globs->thread_states_to_destroy_lock);
if (state->has_main_greenlet()) {
// mark the thread as dead ASAP.
// this is racy! If we try to throw or switch to a
// greenlet from this thread from some other thread before
// we clear the state pointer, it won't realize the state
// is dead which can crash the process.
PyGreenlet* p(state->borrow_main_greenlet().borrow());
assert(p->pimpl->thread_state() == state || p->pimpl->thread_state() == nullptr);
dynamic_cast<MainGreenlet*>(p->pimpl)->thread_state(nullptr);
return true;
}
return false;
}
static void
AddToCleanupQueue(ThreadState* const state)
{
assert(state && state->has_main_greenlet());
// NOTE: Because we're not holding the GIL here, some other
// Python thread could run and call ``os.fork()``, which would
// be bad if that happened while we are holding the cleanup
// lock (it wouldn't function in the child process).
// Make a best effort to try to keep the duration we hold the
// lock short.
// TODO: On platforms that support it, use ``pthread_atfork`` to
// drop this lock.
LockGuard cleanup_lock(*mod_globs->thread_states_to_destroy_lock);
mod_globs->queue_to_destroy(state);
if (mod_globs->thread_states_to_destroy.size() == 1) {
// We added the first item to the queue. We need to schedule
// the cleanup.
// A size greater than 1 means that we have already added the pending call,
// and in fact, it may be executing now.
// If it is executing, our lock makes sure that it will see the item we just added
// to the queue on its next iteration (after we release the lock)
//
// A size of 1 means there is no pending call, OR the pending call is
// currently executing, has dropped the lock, and is deleting the last item
// from the queue; its next iteration will go ahead and delete the item we just added.
// And the pending call we schedule here will have no work to do.
int result = AddPendingCall(
PendingCallback_DestroyQueue,
nullptr);
if (result < 0) {
// Hmm, what can we do here?
fprintf(stderr,
"greenlet: WARNING: failed in call to Py_AddPendingCall; "
"expect a memory leak.\n");
}
}
}
static int
PendingCallback_DestroyQueue(void* UNUSED(arg))
{
// We're may or may not be holding the GIL here (depending on
// Py_GIL_DISABLED), so calls to ``os.fork()`` may or may not
// be possible.
while (1) {
ThreadState* to_destroy;
{
LockGuard cleanup_lock(*mod_globs->thread_states_to_destroy_lock);
if (mod_globs->thread_states_to_destroy.empty()) {
break;
}
to_destroy = mod_globs->take_next_to_destroy();
}
assert(to_destroy);
assert(to_destroy->has_main_greenlet());
// Drop the lock while we do the actual deletion.
// This allows other calls to MarkGreenletDeadAndQueueCleanup
// to enter and add to our queue.
DestroyOne(to_destroy);
}
return 0;
}
static void
DestroyOne(const ThreadState* const state)
{
// May or may not be holding the GIL (depending on Py_GIL_DISABLED).
// Passed a non-shared pointer to the actual thread state.
// state -> main greenlet
assert(state->has_main_greenlet());
PyGreenlet* main(state->borrow_main_greenlet());
// When we need to do cross-thread operations, we check this.
// A NULL value means the thread died some time ago.
// We do this here, rather than in a Python dealloc function
// for the greenlet, in case there's still a reference out
// there.
dynamic_cast<MainGreenlet*>(main->pimpl)->thread_state(nullptr);
delete state; // Deleting this runs the destructor, DECREFs the main greenlet.
}
static int AddPendingCall(int (*func)(void*), void* arg)
{
// If the interpreter is in the middle of finalizing, we can't add a
// pending call. Trying to do so will end up in a SIGSEGV, as
// Py_AddPendingCall will not be able to get the interpreter and will
// try to dereference a NULL pointer. It's possible this can still
// segfault if we happen to get context switched, and maybe we should
// just always implement our own AddPendingCall, but I'd like to see if
// this works first
#if GREENLET_PY313
if (Py_IsFinalizing()) {
#else
if (_Py_IsFinalizing()) {
#endif
#ifdef GREENLET_DEBUG
// No need to log in the general case. Yes, we'll leak,
// but we're shutting down so it should be ok.
fprintf(stderr,
"greenlet: WARNING: Interpreter is finalizing. Ignoring "
"call to Py_AddPendingCall; \n");
#endif
return 0;
}
return Py_AddPendingCall(func, arg);
}
};
};
}; // namespace greenlet
// The intent when GET_THREAD_STATE() is needed multiple times in a
// function is to take a reference to its return value in a local
// variable, to avoid the thread-local indirection. On some platforms
// (macOS), accessing a thread-local involves a function call (plus an
// initial function call in each function that uses a thread local);
// in contrast, static volatile variables are at some pre-computed
// offset.
typedef greenlet::ThreadStateCreator<greenlet::ThreadState_DestroyNoGIL::MarkGreenletDeadAndQueueCleanup> ThreadStateCreator;
static thread_local ThreadStateCreator g_thread_state_global;
#define GET_THREAD_STATE() g_thread_state_global
#endif //T_THREADSTATE_DESTROY