chhsiao1981
commented
3 years ago One caveat is that talk is using kill USR1 / USR2. The users on c-pttbbs will not be able to send message to go-pttbbs. (It's possible that it's ok in reality～)
The main purpose of this setup is to keep user-count up-to-date. (from c-pttbbs/util/shmctl utmpsortd)
An alternative setup is just skipping updating shm.userinfo. Let the users in go-pttbbs treated as hidden-user in c-pttbbs.
Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
https://github.com/ptt/pttbbs/blob/master/mbbsd/mbbsd.c#L953 (mbbsd.setup_utmp)
this is right-after user login / register, to help all kinds of online-user list.
However, there will be only 1 pid in go-pttbbs (go-pttbbs is multi-thread)
Describe the solution you'd like A clear and concise description of what you want to happen.
We would assume that there will be only 1 login per user in go-pttbbs. (If there are multiple-logins, it's still 1 login from go-pttbbs's view. It will be middlewares' responsibility to take care of multiple-logins)
I would like to propose that the pid of the user in go-pttbbs will be PID_MAX + uid (usernum in pttbbs, starting from 1) as the pseudo-pid.
pid-max is defined in kernel.pid_max (sysctl -a)
checked that kill(2) treats pid < 0 as pid-group., and pid == -1 as all processes except system-processes. pid < 0 may not be a good.
There will be the following modifications in setup_utmp and cache.getnewutmpent in go-pttbbs side:
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
Additional context Add any other context or screenshots about the feature request here.