skynet newservice API参考

local skynet = require("skynet")

skynet.start(start_func)

c服务snlua启动后执行的第一个lua文件里面的主逻辑一定是skynet.start(start_func)，由此开始运行lua服务的逻辑

start_func是当前lua服务的初始化函数,也是当前服务的第一个协程的函数

以后在收到非response消息时dispatch_message会建立更多的协程来作逻辑

而调用skynet.start(start_func)的主线程会调度上述这些协程(yield)

dispatch_message(...) 

这就是ctx的消息处理函数(skynet_context.skynet_cb, 返回零(假)时释放消息的内存.那么lua层如何控制呢？c.callback(dispatch_message,false)就是释放内存,c.callback(dispatch_message,true)不释放内存，具体参见vim -t _callback.那么lua层如何控制发消息时不作复制呢？我看skynet.send/call/rawcall都不支持对复制的控制，参见vim -t _send. 底层的默认处理是：对于Lua string直接复制，对于lightuserdata不复制，对于其余类型报错)

dispatch_message将是本服务的发动机(消息驱动机),也就是底层工做线程拿到本服ctx.mq中的一个消息后执行的消息处理函数(vim -t _dispatch_message, 底层由worker thread取到消息后调用这个函数而触发lua函数的调用)，也就是本lua服的主线程(虽然线程ID不固定)

dispatch_message每处理完mq中的一个消息都要遍历并执行消息处理过程当中fork而没运行的新协程(遍历fork_queue并coroutine.resume())

对于收到的每一个非response(prototype!=skynet.PTYPE_RESPONSE)消息启动一个新协程X，用该协程来运行协议类型对应的dispatch函数来处理消息

对于收到的每一个response消息，根据session从session_id_coroutine取出协程并恢复执行

协程X运行业务逻辑时可能会“对其余服务作请求并等待结果”或者“睡眠几秒”，这时协程X用yield抛出“CALL”/“SLEEP”等返回值并挂起，主线程根据yield抛出的值对协程作不一样处理

CALL -> 协程X已对其余服务发出请求并等待回应 -> 主线程把协程X记录到session_id_coroutine中，下次收到对应的response消息(sessionID一致)时唤醒

SLEEP -> 协程X[已调用skynet.sleep(ti)等定时器返回]或[已调skynet.wait()等其余服务返回,这种状况通常须要用skynet.wakeup()来唤醒，不然协程可能永远沉睡下去了] -> 主线程把协程X记录到session_id_coroutine，并记录sleep_session，对于sleep_session须要用skynet.wakeup(co)唤醒 (session_id_coroutine和sleep_session二者怎么维持数据一致，这个细节还须要结合实例再看看 markbyxds )

skynet.newservice(name,...)

建立lua服务 skynet.rawcall(".launcher", "lua" , skynet.pack("LAUNCH", "snlua", name, ...))

实际上是skynet_context_new(module_name("snlua"), param("cmaster"))

即，用snlua服跑着一个lua逻辑服(service/cmaster.lua),snlua创造了一个lua环境的沙盒

除了service/launch.lua自身之外，其余lua服务通常都是由service/launch.lua这个lua服负责建立的

固然，launch服最终仍是调用的skynet.launch("snlua","xxx")来建立服务

skynet.launch 

建立c服务, lualib-src/lua-skynet.c -> skynet_command(CTX,"LAUNCH",..) -> skynet_context_new(mod,args)

对于skynet.launch("snlua","xxx")，这是建立c服务snlua而后在它上面跑lua服务xxx

skynet.monitor(service, query)    监控服务退出,细节还没仔细看 markbyxds

skynet.uniqueservice(global,...) 

建立一个惟一的服务，调用屡次service/***.lua也只启一个实例，好比clusterd和multicastd

global=true时，在全部节点之间是惟一的

实际上是用skynet.call(异步变同步)的方式让service_mgr服务建立目标服务(相似于通知launch服建立服务同样)

service_mgr这边如已建立则直接返回服务地址；如没则建立；如正在建立则等结果

skynet.queryservice(global,...) global=true时

若是尚未建立过目标服务则一直等下去，直到目标服务被(其余服务触发而)建立

skynet.rawcall 

向目标服发送无协议的消息并返回response,协程挂起等返回,用同步代码的样式实现异步逻辑

当 A call B 时，若是 B 在回应前就退出了，A 会收到一条异常，并正确的传播到 A 里的 call 调用处；

当 A call B ，而 B 在回应前，A 本身退出了，B 也会收到一条异常，提示 A 已经不在了。但不会影响 B 的执行流程，只是让框架回收一些必要的相关资源。

skynet.call 跟skynet.rawcall的区别是向目标服发送指定协议的消息

skynet.send 跟skynet.call的区别是仅仅发消息而已，不关心返回值也不会让当前协程挂起(非request-response模式)

skynet.wait() 

把当前协程挂起放入session_id_coroutine/sleep_session

当收到等待的消息(会把消息对应的正在等待session放入wakeup_session中)后该协程恢复执行

skynet.sleep(ti) 

相似于skynet.wait(),只是要事先通知底层定时器

等定时器(在ti时间达到后)发来消息时该协程恢复执行

skynet.wakeup(co) 

若是协程co正处于挂起等待的状态(在sleep_session中)则把它加入wakeup_session

本服务的主协程会在调度过程当中把wakeup_session中的协程唤醒执行

skynet.ret 在当前协程(为处理请求方消息而产生的协程)中给请求方(消息来源)的消息作回应

skynet.retpack 跟skynet.ret的区别是向请求方做回应时要用skynet.pack打包

skynet.register_protocol 

注册协议：

协议名(name)

协议ID(id)

发送消息的打包函数(pack)

接收消息的拆包函数(unpack)

接收消息的(分发)处理函数(dispatch)

已注册的协议记录在lualib/skynet.lua:proto这个数据结构上

每一个服务会默认初始化lua/response/error这几种协议

skynet.dispatch(typename, func) 

修改以typename为协议名的协议：用func这个函数来做为协议的dispatch函数(默认的lua协议没提供dispatch，须要使用者根据业务须要写)

skynet.fork 

建立一个新的协程

这里有作协程对象池来加速，相似于咱们项目中的线程池，建立一堆协程并挂起，接到业务后拿协程跑业务逻辑

skynet.register(name) 

注册当前服务的名字(默认用:%x做为name，本地服务的自定义名以.打头)

把<handleId + name>记录到handle_storage->name,参数必须符合本地服务的命名规范

skynet.self() 返回当前服务的handleID,若是还没注册就先注册(相似于skynet.register)

skynet.harbor(addr) return “addr(ctx的handleID)对应的harborID",boolean(是否远端节点)

skynet.address(addr) return "addr(ctx的handleID或者name)对应的name(string,:%x或者自定义名)"