Ruk33/l2auth

Documentation - Threads

Ruk33 opened this issue · 4 comments

Ruk33 commented

Threads can be hard and very easy to be misused. Especially if locks and releases are all over the code.
In order to avoid complexity, each thread will be in charge of accessing and updating its own resources.

For example:

We may have a thread for characters that will deal with players and NPCs.
We may also have a buffs thread that will deal with the ticks of each buff. Assume there is a buff that takes 5 life points out of a character every 10 seconds. Instead of the buffs threads directly updating the character's life, the buffs thread will add a new request into the work queue so that later, the character's thread can pick it up and perform the required updates.

Each thread will be constantly checking in the work queue to see if there is a request to be handled by it.
The work queue is documented in another issue and there will be a lock/release for every queue/dequeue.

My main concern with this approach is that we may not use the computer's resources to their fullest. How many threads are per core? how many threads will be idle doing nothing?

Also, how should each thread read another's threads resources? would it be "good enough" to just read and accept the fact that we may be computing values based on old state?

Hi,

Looking at this, it looks a bit like the actor model :) I am also working on a project for Lineage 2 but using Erlang programming language.

Regards,

Alo

Ruk33 commented

Hey @alokhan , thanks for the comment. Will take a look at that pattern.

Ruk33 commented

Thanks @alokhan , I was able to read through it, and seems like that's the pattern although now, I'm debating if I really want/need to use threads for this project. Maybe just a work queue would be enough...

Ruk33 commented

Only one thread will be used until more are needed.