lailongwei/llbc

一个简洁、高效、跨平台、多语言支持的服务端开发框架，面向Service及Component，底层c++实现。

llbc's Issues

【llbc】LLBC_Variant一处比较优化

当前LLBC_Variant的 string、number比较实现中，是number to string后进行比较，根据实际使用情况来看，大部分情境都是要求string to number后再进行比较，可以整体再评估一下，以确定是否进行string to number的比较优化

【llbc】ThreadManager提供hook机制

如题，提供hook能力，可让业务更灵活监控线程创建、销毁、运行时间相关信息

【llbc】标准化XXX管理器命名

LLBC_XXXManager -> LLBC_XXXMgr

【llbc】Stream operator >> 考虑采用异常方式反馈错误

当前使用LLBC_Stream::operator>>内部失败时，无法获得任何错误信息，这是由语言设计本身决定，只能在此处使用异常方式来反馈，但llbc框架整体是摒弃异常设计的，如果只在此处引入是否合理，需要进行评估

【llbc】框架中volatile使用问题排查

【llbc】Service完整简化、梳理

【llbc】LLBC_Stream arithmetic数据类型引入protobuf相同的数据压缩算法

如题，为确保LLBC_Stream序列化、反序列化后的数据长度，需要为arithmetic数据类型引入protobuf相同的数据编解码算法

【llbc】提升LLBC_STLHelper性能

LLBC_STLHelper目的是为了释放stl容器远程内存而编写，当前性能较差，需要进行性能提升

【llbc】整体简化llbc内部使用Task的逻辑

【llbc】过长变量名定义统一使用auto

llbc框架编写之初是支持非c++11编译器编译使用的，随着时间推移，已经不需要再作支持，取消支持后，一大块需要简化的代码就是过长的变量定义时的变量名，可整体简化成auto

【all】Json格式Log增加timestamp自动输出支持

【llbc】LLBC_Task优化：确保所有线程离开Svc()方法后才更新TaskState到Deactivating

LLBC_Task优化：确保所有线程离开Svc()方法后才更新TaskState到Deactivating#150

【llbc】LLBC_Variant支持std::unordered_xxx容器

如题

【llbc】实现LoggerMgr的IsInited()方法

【llbc】对象池设计、代码简化（必要时进行重构）

Mac 平台上make core_lib编译无法成功

Mac平台上make core_lib 编译不通过

【llbc】for test add issue

【llbc】统一化LLBC_Guard

通过泛型特化方式，对llbc框架中各种LLBC_XXXGuard进行统一，只保留一个LLBC_Guard类，以确保实际使用的简单跟概念的统一

【llbc】确保业务自定义协议栈中发包的正确性

当前Service::Send()类接口在进行发包时, 将进行sessionId有效性校验，而session信息添加时机是：Service处理SessionCreate事件时，这导致一个问题：

如果业务重写了协议栈，并在协议栈就进行发包，将有可能发包失败，因为收到包的时候，Service会话信息可能还未建立

所以，需要：Service层会话信息添加前置到Poller线程会话建立的时候就添加，以确保自定义协议栈开发者可在协议栈中就可发包

【llbc】LLBC_Stream完整改进

集中于以下几点：

• Read()/Write()对stl containers的适配改进（使用LLBC_IsTemplSpec<>模板推导），包括以下适配：
  • stl unary containers：std::vector、std::list、std::queue、std::deque、 std::stack、std::set、std::unordered_set、std::array
  • stl binary containers：std::map、std::unordered_map
  • stl other datatypes: std::pair、std::tuple、std::array
  • others: LLBC_String、LLBC_CString、T []、std::string/LLBC_String/std::string/char []互转、const char *(同时阻止char * read)
• Read()/Write()核心性能改进：
  • 旧有代码进行Container Elem的读取时，会构造临时对象，再进行push，将进行三个主要优化：
    • push -> emplace：去除不必要的copy construct（使用move construct）
    • 临时对象进行emplace()调用时，进行std::move，确保move construct生效
    • 临时对象复用，旧有Stream逻辑内部未进行复用
• Read()操作失败时的必要内存归还
  • 当前Read() stl container失败时并未归还stl container分配的内存，导致业务可能的内存OOM问题出现，需要在失败时进行swap()方式的内存释放
• 必要的接口、代码规整
• 提供Move Construct、Move Assignment支持

【llbc】实现Func Trace支持宏

实现Func Trace宏功能，以支持Trace函数执行时间、调用次数、频度、内存信息

【llbc】对象池相关优化

对象池代码编写较为仓促，可以做较大优化：

• 将Reuse/Reflection相关合并成一个概念，并将相关类及代码统一
• 整体简化代码及数据结构定义，优化Get/GetObject/GetReferencable这些模棱两可接口，统一变成Alloc/Recycle
• 增加自动收缩、手动收缩支持，以确保不会因为某时刻运行时的问题对app后续运行造成过大的内存压力
• 提升性能

【llbc】LLBC_Num2Str去除或优化

【llbc】App/Svc层面支持运行时日志输出

Application、Service为llbc框架中较重度的两个调试及类，需要有一套运行时日志设计，并以Hook方式让外部获取并最终进行打印

【llbc】ThreadManager/Task完整重构、改进

ThreadManager、Task两块代码为10年前编写，代码设计及实现较差，且存在一些Bug，在些进行完整重构，主要着重以下几点：

• 解耦ThreadManager中的Task耦合
• 简化所有ThreadManager、Task接口设计
• 完整重构两部分代码，使代码简洁、优雅
• 完整编写测试用例，并进行必要测试

【llbc】去除各非顶层模块目录中子目录下的Common.h头文件

如题，确保框架头文件的简单、清晰

【pyllbc】Facade支持onsessionexception

对Facade增加onsessionexception方法支持，以更通用处理会话异常，而不是只能通过订阅完成
对应风车单：https://fengche.co/users/fe98e3e6745f/tickets/7ff9a9d7d3f0

【llbc】标准化BinaryHeap接口

当前BinaryHeap接口跟stl container有较大差异，为确保统一、理解跟使用的简单性，需要对BinaryHeap接口进行stl container like调整

【llbc】Log增加Ctx设置跟获取支持

在Log实际使用中，一个函数往往要在多处输出Log，输出Log中部分信息是一样的，这导致这些日志输出存在大量重复代码，在此新增一个日志上下文(LogCtx)的概念，一个函数有一个上下文，业务可以操作，在日志输出时，框架会自动附着上下文并输出

【llbc】优化LLBC_ServiceMgr::GetService()性能

如题

【llbc】提供统一的to_string支持

通过类型探测、方法探测，提供to_string支持

【llbc】LLBC_ComponentFactory::Create增加service传入

如题，增加service传入，以确保Factory实现可以更灵活，如根据不同service name来创建不同的Component实现

【llbc】去除LLBC_MessageBlock，使用功能更完整、更强大的LLBC_Stream代替

当前LLBC_MessageBlock功能跟LLBC_Stream有重叠，且只是为LLBC_Stream的子集，为减少类定义、功能统一（包括LLBC_Coder的改造），可以考虑将LLBC_MessageBlock去除，使用LLBC_Stream代替

【llbc】LLBC_Component方法收敛

当前LLBC_Component事件方法设计上，存在以下两个问题：

1. 事件方法除了Component流程必要的OnInit、OnDestroy、OnStart、OnStop、OnUpdate、OnIdle外，其他所有方法都是跟特定功能相关，方法众多，使得LLBC_Component看上去过于复杂且耦合过大，后期扩展也会使得事件方法接口不受控膨胀
2. 事件方法只能由框架定义并使用，业务在使用LLBC_Component时，如果两个业务逻辑组件有强事件交互，将没有办法使用这一套事件方法机制，只能借助LLBC_EventManager之类的方式来传递，这使得LLBC_Component事件方法机制受限（即不能开放给业务使用），一个例子：
   • 业务有一个自己的网络组件，所有上层业务组件都使用这个网络组件进行通讯，这个组件名字叫XXXNetComp，它有两个最基本的事件：OnXXXNetConnect/OnXXXNetDisconnect，如果没有通用的事件方法机制，那么其他组件编写者只能在自己组件的OnInit方法中进行eventMgr.AddListener(...)这样的弱关联写法，导致代码相对复杂及臃肿

---

方法收敛的一种方式：

• LLBC_Component除了必要流程方式保留OnXXX()外，只提供一种事件方法OnEvent()，框架跟业务统一使用，这样达到了所有方法收敛的效果，业务派遣事件、处理事件也变得更简单

【pyllbc】优化python layer packet构造性能

根据python源码，在每次进行python层packet构造时，都会有一次tuple的构造开销，源码如下：

/* 调用callable对象，在这里的callable为packet class */
PyObject *
PyObject_CallMethodObjArgs(PyObject *callable, PyObject *name, ...)
{
    PyObject *args, *tmp;
    va_list vargs;

    if (callable == NULL || name == NULL)
        return null_error();

    callable = PyObject_GetAttr(callable, name);
    if (callable == NULL)
        return NULL;

    /* count the args */
    va_start(vargs, name);
    args = objargs_mktuple(vargs);  // 此处创建tuple
    va_end(vargs);
    if (args == NULL) {
        Py_DECREF(callable);
        return NULL;
    }
    tmp = PyObject_Call(callable, args, NULL);
    Py_DECREF(args);
    Py_DECREF(callable);

    return tmp;
}

/* tuple对象构建实现，可以看到内部将创建新tuple，并逐个元素incref后放入tuple */
static PyObject *
objargs_mktuple(va_list va)
{
    int i, n = 0;
    va_list countva;
    PyObject *result, *tmp;

#ifdef VA_LIST_IS_ARRAY
    memcpy(countva, va, sizeof(va_list));
#else
#ifdef __va_copy
    __va_copy(countva, va);
#else
    countva = va;
#endif
#endif

    while (((PyObject *)va_arg(countva, PyObject *)) != NULL)
        ++n;
    result = PyTuple_New(n);
    if (result != NULL && n > 0) {
        for (i = 0; i < n; ++i) {
            tmp = (PyObject *)va_arg(va, PyObject *);
            PyTuple_SET_ITEM(result, i, tmp);
            Py_INCREF(tmp);
        }
    }
    return result;
}

需要在协议包构建的时候，使用缓存的tuple对象来进行协议包构建

【llbc】标准化llbc error处理相关函数

当前llbc框架中对错误码的处理函数命名相对不统一，需要进行统一，有些地方是Error，有些地方是Errno

【llbc】LLBC_Singleton记录已初始化的对象，并在框架销毁时进行栈式清理

如题

Log建议增加一个开关，初始化时不要创建空的logger文件，只有第一次输出时才创建

RT

【llbc】组件App相关事件方法简化

Application -> App
Config -> Cfg

【llbc】LLBC_Application命名简化

App类命名较长，实际使用不太需要全拼，使用约定俗成的简拼即可：LLBC_Application -> LLBC_App

【llbc】LLBC_Variant支持LLBC_CString

如题

【llbc】LLBC_Variant支持用户自定义类型

如题，使得LLBC_Variant托管一些简单的用户自定义类成为可能，而不再是AsPtr<UserClass>()的方式来使用

【llbc】实现c# using or python with原语

llbc-python3编译失败

[root@ysz llbc]# make py_wrap
Python 2.6.6
Building configurations...
Running action 'gmake'...
Done (2080ms).
make[1]: Entering directory /home/llbc/build/gmake' make[1]: Leaving directory /home/llbc/build/gmake'
make[1]: Entering directory `/home/llbc/build/gmake'
Running prebuild commands
python ../../tools/building_script/py_prebuild.py pyllbc
Build methods... Done
Build script integrator... Done
Application.cpp
In file included from ../../wrap/pyllbc/include/pyllbc/common/ObjAttrOptr.h:76:0,
from ../../wrap/pyllbc/include/pyllbc/common/Common.h:33,
from ../../wrap/pyllbc/include/pyllbc/application/PyApplication.h:25,
from ../../wrap/pyllbc/src/application/Application.cpp:24:
../../wrap/pyllbc/include/pyllbc/common/ObjAttrOptrImpl.h: In member function ‘int pyllbc_ObjAttrOptr::SetAttr(const LLBC_String&, const _Val&) [with _Val = llbc::LLBC_BasicString; llbc::LLBC_String = llbc::LLBC_BasicString]’:
../../wrap/pyllbc/include/pyllbc/common/ObjAttrOptrImpl.h:300:71: error: ‘PyString_FromStringAndSize’ was not declared in this scope
PyObject oVal = PyString_FromStringAndSize(val.data(), val.size());
^
../../wrap/pyllbc/include/pyllbc/common/ObjAttrOptrImpl.h: In member function ‘int pyllbc_ObjAttrOptr::SetAttr(const LLBC_String&, const _Val&) [with _Val = char; llbc::LLBC_String = llbc::LLBC_BasicString]’:
../../wrap/pyllbc/include/pyllbc/common/ObjAttrOptrImpl.h:311:45: error: ‘PyString_FromString’ was not declared in this scope
PyObject *oVal = PyString_FromString(val);
^
../../wrap/pyllbc/include/pyllbc/common/ObjAttrOptrImpl.h: In member function ‘int pyllbc_ObjAttrOptr::SetAttr(const LLBC_String&, const _Val&) [with _Val = long int; llbc::LLBC_String = llbc::LLBC_BasicString]’:
../../wrap/pyllbc/include/pyllbc/common/ObjAttrOptrImpl.h:344:40: error: ‘PyInt_FromLong’ was not declared in this scope
PyObject *oVal = PyInt_FromLong(val);

【llbc】EventMgr.stub调整为进程唯一自增

为确保进程中多处使用EventMgr导致的可能的业务使用不配对的EventMgr进行stub remove操作，将修改为stub全进程唯一自增

【llbc】LLBC_FilePrint/LLBC_Print改进

针对易用性、格式化检查、性能进行如下改进：

• LLBC_XXXLine()更新为LLBC_XXXLn()
• 增加格式化检查（gcc/clang only）
• 去除FilePrint内部的flush()操作
• 格式化实现优化，提升性能

【llbc】将core/os层的大部分函数变成内部函数(__LLBC_前缀)

为确保业务不使用core/os层面的接口，将接口进行内部化，同时也可以减少框架使用的歧义，如线程接口的使用。

【llbc】Log支持泛洪日志丢弃能力

业务使用时，如果存在短时间巨量日志输出，会直接将内存撑爆，从而导致OOM或Crash，因此，Log组件需要支持泛洪日志丢弃能力

日志的配置比较冗余，违反了 DRY 原则，希望可以优化下配置方式

# 地图
map.level=DEBUG
map.asynchronous=true
map.flushInterval=500
map.logToConsole=false
map.consoleLogLevel=DEBUG
map.consolePattern=%T [%-5L][%g][ %f:%l ] - %m%n
map.logToFile=true
map.logFile=syslog/map
map.filePattern=%T [%-5L][%g][ %f:%l ] - %m%n
map.dailyRollingMode=true
map.maxBackupIndex=1
map.lazyCreateLogFile=true
map.logFileSuffix=.log

# 英雄
hero.level=DEBUG
hero.asynchronous=true
hero.flushInterval=500
hero.logToConsole=true
hero.consoleLogLevel=DEBUG
hero.consolePattern=%T [%-5L][%g][ %f:%l ] - %m%n
hero.logToFile=true
hero.logFile=syslog/hero
hero.filePattern=%T [%-5L][%g][ %f:%l ] - %m%n
hero.dailyRollingMode=true
hero.maxBackupIndex=1
hero.lazyCreateLogFile=true
hero.logFileSuffix=.log

项目实际使用时，同一份配置里的 logger，大部分是相同的，只有名字不同，冗余信息严重。

【llbc】Stack backtrace增加时间信息打印

如题，当前Stack backtrace未体现crash time，需要增加crash time输出