Skynet NewService API Reference

Local Skynet = require ("Skynet")

Skynet.start (Start_func)

C Service Snlua The main logic inside the first LUA file executed after startup must be Skynet.start (START_FUNC), which starts the logic of running the LUA service

Start_func is the initialization function of the current LUA service and the function of the first co-process of the current service

Then dispatch_message creates more threads to do the logic when the non-response message is received

The main thread of the call to Skynet.start (Start_func) dispatches the above-mentioned association (yield)

Dispatch_message (...)

This is the CTX message handler function (SKYNET_CONTEXT.SKYNET_CB, which returns 0 (false) when the message is freed. So how does the LUA layer control it? C.callback (Dispatch_message,false) is the release of Memory, C.callback (dispatch_message,true) do not release memory, see Vim-t _ Callback. How does the LUA layer control the message when it does not replicate? I don't see Skynet.send/call/rawcall support for replication control, see Vim-t _send. The underlying default processing is: Direct replication for LUA strings, no replication for Lightuserdata, error for other types)

The

Dispatch_message will be the engine of the service (message driver), which is the message handler function (Vim-t _dispatch_message, executed by the underlying worker when it gets a message in ctx.mq). The bottom layer is called by the worker thread to invoke this function to trigger the LUA function call), which is the main thread of this LUA service (although the threading ID is not fixed)

Dispatch_ Each message in MQ is traversed and executed with a new thread that is not running during message processing (traversing Fork_queue and Coroutine.resume ())

For each non-response received ( Prototype!=skynet. Ptype_response) message starts a new coprocessor X, which runs the dispatch function corresponding to the protocol type to process the message

For each RESPONSE message received, according to the session from the SESSION_ID_ When Coroutine takes out the process and resumes execution of the

Coprocessor, it may "request and wait for the result" or "sleep for a few seconds" when running the business logic, and the process X throws a return value such as "call"/"sleep" with yield and hangs, The main thread does different processing according to the value thrown by the yield

Call--, the main thread that has made a request to another service and waits for a response, to log the coprocessor x into the Session_id_coroutine, The next time you receive the corresponding response message (SessionID consistent), Wake

SLEEP-----x[called Skynet.sleep (TI), etc., or other services such as skynet.wait () returned, This situation generally needs to use Skynet.wakeup () to wake up, otherwise the association may Sleep forever], the main thread to record the association X to Session_id_coroutine, and record sleep_session, for Sleep_ The session needs to be woken up with Skynet.wakeup (CO) (Session_id_coroutine and Sleep_session maintain data consistency, and this detail needs to be combined with an example to see MARKBYXDS)

Skynet.newservice (name,...)

Create a LUA service Skynet.rawcall (". Launcher", "Lua", Skynet.pack ("LAUNCH", "Snlua", Name, ...))

In fact is skynet_context_new (Module_name ("Snlua"), param ("Cmaster"))

That is, using Snlua to run a LUA logic service (Service/cmaster.lua), Snlua created a sandbox for the LUA environment

In addition to Service/launch.lua itself, other LUA services are typically created by Service/launch.lua, the LUA server.

Of course, launch will eventually call the Skynet.launch ("Snlua", "xxx") to create the service

Skynet.launch

Create a C service, lualib-src/lua-skynet.c-Skynet_command (CTX, "LAUNCH",..), Skynet_context_new (Mod,args)

For Skynet.launch ("Snlua", "xxx"), this is to create a C service Snlua and then run the LUA service XXX on it

skynet.monitor (service, query) monitoring service exit, details have not been carefully read Markbyxds

Skynet.uniqueservice (Global,...)

Create a unique service that calls multiple Service/***.lua and only one instance, such as Clusterd and MULTICASTD

Global=true, it is unique between all nodes

In fact, the Service_mgr service is created using Skynet.call (asynchronous sync) to create the target service (similar to the Notification launch service creates the services)

Service_mgr this side, if created, returns the service address directly; if not, create a result such as you are creating

Skynet.queryservice (Global,...) When Global=true

If the target service has not been created yet, wait until the target service is created (triggered by another service)

Skynet.rawcall

Sends an protocol-free message to the target service and returns response, the thread hangs, and so on, implementing asynchronous logic with the style of the synchronous code

When a call B, if B exits before the response, a will receive an exception, and correctly propagate to a in the calls office;

When a call B, and B before the response, a self exit, B will also receive an exception, indicating that a is no longer. But it does not affect the execution of B, it simply allows the framework to reclaim some of the necessary related resources.

The difference between Skynet.call and Skynet.rawcall is the message that sends the specified protocol to the target service.

The difference between skynet.send and Skynet.call is that it only sends messages, doesn't care about the return value and does not let the current thread hang (non-request-response mode)

Skynet.wait ()

Suspends the current coprocessor into session_id_coroutine/sleep_session

When the waiting message is received (the message corresponding to the waiting session is put into the wakeup_session), the process resumes execution

Skynet.sleep (TI)

Similar to skynet.wait (), just to notify the underlying timer in advance

Wait for the timer (after Ti time is reached) to send a message when the process resumes execution

Skynet.wakeup (CO)

If the CO is in a pending state (in sleep_session), add it to the Wakeup_session

The main process of the service will execute the wakeup_session during the scheduling.

Skyne. RET responds to the message from the requester (the source) in the current process (the coprocessor generated for processing the requester message)

The difference between Skynet.retpack and Skynet.ret is that when responding to a requester, you use Skynet.pack to package

Skynet.register_protocol

Registration Agreement:

Protocol name (name)

Protocol ID (ID)

Package function (pack) for sending messages

The unpacking function that receives the message (unpack)

Receive message (distribution) handler function (Dispatch)

The registered protocol is recorded on the Lualib/skynet.lua:proto data structure.

Each service will default to initialize the Lua/response/error protocol

Skynet.dispatch (TypeName, func)

Modify the protocol with TypeName as the protocol name: Use the Func function as the dispatch function of the protocol (the default LUA protocol does not provide dispatch, requiring the user to write according to business needs)

Skynet.fork

Create a new co-process

Here are the process object pools to speed up, similar to the thread pool in our project, create a bunch of threads and hang it, get the business after the service to run the business logic

skynet.register (name)

Register the name of the current service (default:%x as name, the custom name of the local service starts with a.)

Record

skynet.self () returns the Handleid of the current service and registers if it is not registered (similar to skynet.register)

Skynet.harbor (addr) return "addr (ctx Handleid) corresponding to Harborid", Boolean (whether remote node)

skynet.address (addr) return "addr (ctx Handleid or name) corresponding to name (string,:%x or custom name)"

Skynet NewService API Reference