- 主题:有没有统计已注册用户数的代码？
daemon/下面的程序是静态连接libBBS/下面的库的，所以你修改了libBBS/下面的文件
就需要重新连接daemon/下面的程序
特别是miscd是负责new新帐号的
【 在 cometcaptor (参宿四[☆]一闪一闪亮晶晶) 的大作中提到: 】
: 好复杂……我先把整个代码打个包重新config和make一下试试
--
FROM 61.182.213.*
把libBBS里的文件复制了一下，终于OK了……谢谢at3p~~~~
【 在 atppp (Big Mouse) 的大作中提到: 】
: daemon/下面的程序是静态连接libBBS/下面的库的，所以你修改了libBBS/下面的文件
: 就需要重新连接daemon/下面的程序
: 特别是miscd是负责new新帐号的
: ...................
--
FROM 211.151.95.*
还有个问题，我如果要在update_user里把idnumber+1是不是也要ucache_lock
【 在 cometcaptor (参宿四[☆]一闪一闪亮晶晶) 的大作中提到: 】
: 把libBBS里的文件复制了一下，终于OK了……谢谢at3p~~~~
--
FROM 211.151.95.*
如果可能有多个进程同时在执行idnumber++就要锁，否则就无所谓，看你怎么设计的了
【 在 cometcaptor (参宿四[☆]一闪一闪亮晶晶) 的大作中提到: 】
: 还有个问题，我如果要在update_user里把idnumber+1是不是也要ucache_lock
--
FROM 61.182.213.*
我只有在countidnumber的时候有可能给idnumber赋值……这么还是把它锁掉吧，保险点
update_user里对uidshm的更新是memcpy的，但其本身没有锁ucache,是不是在调用处锁
的？还是update本身不用锁？
【 在 atppp (Big Mouse) 的大作中提到: 】
: 如果可能有多个进程同时在执行idnumber++就要锁，否则就无所谓，看你怎么设计的了
--
FROM 211.151.95.*
memcpy不是原子的，理论上应该是要锁的吧。不过这地方出错的概率很小吧，
也许因此就没锁。
【 在 cometcaptor (参宿四[☆]一闪一闪亮晶晶) 的大作中提到: 】
: 我只有在countidnumber的时候有可能给idnumber赋值……这么还是把它锁掉吧，保险点
: update_user里对uidshm的更新是memcpy的，但其本身没有锁ucache,是不是在调用处锁
: 的？还是update本身不用锁？
: ...................
--
FROM 61.182.213.*
好像ucache.c里有处是先lock再update_user的，看来不能锁……
【 在 atppp (Big Mouse) 的大作中提到: 】
: memcpy不是原子的，理论上应该是要锁的吧。不过这地方出错的概率很小吧，
: 也许因此就没锁。
--
FROM 211.151.95.*
郁闷了……加了个uidshm->idnumber++;就会出现“由于某些系统原因”了
【 在 cometcaptor (参宿四[☆]一闪一闪亮晶晶) 的大作中提到: 】
: 好像ucache.c里有处是先lock再update_user的，看来不能锁……
--
FROM 211.151.95.*
我也用memcpy来实现它看看吧。那么读这个变量的时候是无需lock了吧？？
【 在 cometcaptor (参宿四[☆]一闪一闪亮晶晶) 的大作中提到: 】
: 郁闷了……加了个uidshm->idnumber++;就会出现“由于某些系统原因”了
--
FROM 211.151.95.*
在update_user里加了个uidshm->idnumber += 1;发现每注册一个ID idnumber会加2……
最终决定在load和flush ucache的时候统计一下算了，这样就等于每天更新一次已有账
号数了
【 在 cometcaptor (参宿四[☆]一闪一闪亮晶晶) 的大作中提到: 】
: 我也用memcpy来实现它看看吧。那么读这个变量的时候是无需lock了吧？？
--
FROM 211.151.95.*