荔园在线

荔园之美,在春之萌芽,在夏之绽放,在秋之收获,在冬之沉淀

[回到开始] [上一篇][下一篇]


发信人: jjk (Welcome to InstallBBS,Linux!), 信区: InstallBBS
标  题: 【合集】将menu.ini放进共享内存
发信站: 荔园晨风BBS站 (Thu Dec 27 17:50:15 2001), 转信

【 以下文字转载自 jjk 的信箱 】
【 原文由 jjksam.bbs@melon.gznet.edu.cn 所发表 】
发信人: tonydudu (最爱小企鹅和小魔鬼), 信区: InstallBBS
标  题: 【合集】将menu.ini放进共享内存
发信站: 华南网木棉站 (Sun Dec 23 22:08:36 2001), 转信

发信人: monster (光光万岁), 信区: BBSDEV_Z
标  题: 【合集】将menu.ini放进共享内存
发信站: 我吐。。。 (Sun Dec 23 10:35:39 2001), 站内信件
quickmouse.bbs@bbs.nju.edu.cn 于  Thu Dec 20 22:51:30 2001 提到:
这几天狂写测试代码终于有了结果,由于对程序结构改动比较大,
这里不给出源代码,仅给出一些相关信息。
优势: 节省进程占用的内存,引入一组数据重组结构,占用600B,将原来
       menu.ini所占用的内存放入shm当中(典型占用10~20k不等),如果
       不计shm分摊到每个进程的占用数目,那么新方式占用内存的数目为
       原来的4%~15%;其次,用户可以不重新登陆就可以使用新的界面
缺点:由于每次进入主选单时都需要重新定位显示位置和函数指针,将使得
      程序运算量有轻微增长;在刷新menu.ini的时候有可能造成某些用户
      操作失败(在主选单上),也有隐含的造成用户掉线的可能(估计可能
      性很小);如果menu.ini错误,有可能导致所有用户掉线(因为共享的
      缘故),这样站长无法在检测到menu.ini刷新错误的情况下用另外的
      窗口恢复。
    这里,主要的优缺点都是由于现在fb里面menu.ini在每个进程当中都是
独立的互不影响的空间,而放入shm当中后变为共享而带来的。
    想听听大家的看法,究竟值不值得。
============================================================================
==
allstar.bbs@bbs.nju.edu.cn 于  Thu Dec 20 22:51:33 2001 提到:
【 在 quickmouse (碰猫死翘翘) 的大作中提到: 】
: 这几天狂写测试代码终于有了结果,由于对程序结构改动比较大,
: 这里不给出源代码,仅给出一些相关信息。
: 优势: 节省进程占用的内存,引入一组数据重组结构,占用600B,将原来
:        menu.ini所占用的内存放入shm当中(典型占用10~20k不等),如果
:        不计shm分摊到每个进程的占用数目,那么新方式占用内存的数目为
:        原来的4%~15%;其次,用户可以不重新登陆就可以使用新的界面
: 缺点:由于每次进入主选单时都需要重新定位显示位置和函数指针,将使得
:       程序运算量有轻微增长;在刷新menu.ini的时候有可能造成某些用户
:       操作失败(在主选单上),也有隐含的造成用户掉线的可能(估计可能
                                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
可能性小破坏力不小,比如你新增了一个菜单项,这时原来的区域可能放不下,你必然

改变此菜单项的内存首地址,另外malloc一个内存区出来,如果此时一个用户正在
读你原来的菜单数据,而正在这时被你释放掉的内存刚好被某个程序重新分配。。。
后果就不需要我说了吧。。。
虽说这种机率很小,但一个成熟的BBS是不能存在这种BUG的
不过可以考虑设一些多余的菜单项,这样新增就不需要malloc了,不改变首地址
适当考虑刷新一瞬间的处理方式,也许不会出现上面的问题
:       性很小);如果menu.ini错误,有可能导致所有用户掉线(因为共享的
:       缘故),这样站长无法在检测到menu.ini刷新错误的情况下用另外的
:       窗口恢复。
:     这里,主要的优缺点都是由于现在fb里面menu.ini在每个进程当中都是
: 独立的互不影响的空间,而放入shm当中后变为共享而带来的。
:     想听听大家的看法,究竟值不值得。
============================================================================
==
quickmouse.bbs@bbs.nju.edu.cn 于  Fri Dec 21 00:51:49 2001 提到:
刷新也不会改变内存的首地址。
数据共享首先需要解决的是数据重定位的问题,刷新需要解决的是让
刷新前后的数据定位区域不能改变。原来sysconf.img是变长的结构
由menuitem、sysvar和sysconf_buf三个不定长部分构成,改成shm
方式以后,menuitem和sysvar占据空间定长,sysconf_buf变长但保留定长结构,这样
在每个进程里面,对于三个指针的首址定位都可以预先知道,刷新数据
的时候需要预先对数据进行重定位工作才能写到shm里面去,以确保
每个进程不会发生越界访问的情况。
build的时候需要malloc的,在从malloc的内存当中复制数据到shm的过程当中需要
重定位指针。在主菜单上,按键之前就会定位好函数指针地址,如果按键以后发现
刷新,那么会重头再定位一次且使用户按键失效;如果在判断没有刷新之后由于
切换进程又发生刷新,最多是传给函数的参数出现错误,但是由于参数都是字符串
变量,并且在sysconf_buf定长的最后用了NULL,应该不会出现越界访问问题
具体的代码我要整理一下才贴出来,改动比较大。
【 在 allstar (满天星) 的大作中提到: 】
: 【 在 quickmouse (碰猫死翘翘) 的大作中提到: 】
: : 这几天狂写测试代码终于有了结果,由于对程序结构改动比较大,
: : 这里不给出源代码,仅给出一些相关信息。
: : 优势: 节省进程占用的内存,引入一组数据重组结构,占用600B,将原来
: :        menu.ini所占用的内存放入shm当中(典型占用10~20k不等),如果
: :        不计shm分摊到每个进程的占用数目,那么新方式占用内存的数目为
: :        原来的4%~15%;其次,用户可以不重新登陆就可以使用新的界面
: : 缺点:由于每次进入主选单时都需要重新定位显示位置和函数指针,将使得
: :       程序运算量有轻微增长;在刷新menu.ini的时候有可能造成某些用户
: :       操作失败(在主选单上),也有隐含的造成用户掉线的可能(估计可能
:                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: 可能性小破坏力不小,比如你新增了一个菜单项,这时原来的区域可能放不下,你必
然要
: 改变此菜单项的内存首地址,另外malloc一个内存区出来,如果此时一个用户正在
: 读你原来的菜单数据,而正在这时被你释放掉的内存刚好被某个程序重新分配。。。

: 后果就不需要我说了吧。。。
: 虽说这种机率很小,但一个成熟的BBS是不能存在这种BUG的
: 不过可以考虑设一些多余的菜单项,这样新增就不需要malloc了,不改变首地址
: 适当考虑刷新一瞬间的处理方式,也许不会出现上面的问题
: :       性很小);如果menu.ini错误,有可能导致所有用户掉线(因为共享的
: :       缘故),这样站长无法在检测到menu.ini刷新错误的情况下用另外的
: (以下引言省略 ... ...)
============================================================================
==
zhch.bbs@bbs.nju.edu.cn 于  Fri Dec 21 10:52:14 2001 提到:
我觉得要改的话可以改大一点,不一定要和FB原来的menu.ini格式兼容。
FB的menu.ini处理方法可以说是很复杂的,而且编程风格和其他部分有一些区别,
也许也是从其他地方移植过来的。
menu.ini如果要放在shm里面,数据都采用定长格式可能会比较方便。函数指针
在bbs代码变化后可能发生变化,因此放在shm中没有什么意义,但可以初始化时
一次性给出吧,不一定每次都要重定位吧。
另外,menu.ini变大时,shm需要扩展长度你打算如何处理?可能得事先设个最大值。
【 在 quickmouse (碰猫死翘翘) 的大作中提到: 】
: 这几天狂写测试代码终于有了结果,由于对程序结构改动比较大,
: 这里不给出源代码,仅给出一些相关信息。
: 优势: 节省进程占用的内存,引入一组数据重组结构,占用600B,将原来
:        menu.ini所占用的内存放入shm当中(典型占用10~20k不等),如果
:        不计shm分摊到每个进程的占用数目,那么新方式占用内存的数目为
:        原来的4%~15%;其次,用户可以不重新登陆就可以使用新的界面
: 缺点:由于每次进入主选单时都需要重新定位显示位置和函数指针,将使得
:       程序运算量有轻微增长;在刷新menu.ini的时候有可能造成某些用户
:       操作失败(在主选单上),也有隐含的造成用户掉线的可能(估计可能
:       性很小);如果menu.ini错误,有可能导致所有用户掉线(因为共享的
:       缘故),这样站长无法在检测到menu.ini刷新错误的情况下用另外的
:       窗口恢复。
:     这里,主要的优缺点都是由于现在fb里面menu.ini在每个进程当中都是
: 独立的互不影响的空间,而放入shm当中后变为共享而带来的。
:     想听听大家的看法,究竟值不值得。
============================================================================
==
ttli.bbs@bbs.nju.edu.cn 于  Fri Dec 21 11:52:16 2001 提到:
  似的
【 在 zhch 的大作中提到: 】
: 我觉得要改的话可以改大一点,不一定要和FB原来的menu.ini格式兼容。
: FB的menu.ini处理方法可以说是很复杂的,而且编程风格和其他部分有一些区别,
: 也许也是从其他地方移植过来的。
: menu.ini如果要放在shm里面,数据都采用定长格式可能会比较方便。函数指针
: 在bbs代码变化后可能发生变化,因此放在shm中没有什么意义,但可以初始化时
: 一次性给出吧,不一定每次都要重定位吧。
: 另外,menu.ini变大时,shm需要扩展长度你打算如何处理?可能得事先设个最大值。

: 【 在 quickmouse (碰猫死翘翘) 的大作中提到: 】
: : 这几天狂写测试代码终于有了结果,由于对程序结构改动比较大,
: : 这里不给出源代码,仅给出一些相关信息。
: : 优势: 节省进程占用的内存,引入一组数据重组结构,占用600B,将原来
: :        menu.ini所占用的内存放入shm当中(典型占用10~20k不等),如果
: :        不计shm分摊到每个进程的占用数目,那么新方式占用内存的数目为
: :        原来的4%~15%;其次,用户可以不重新登陆就可以使用新的界面
: : 缺点:由于每次进入主选单时都需要重新定位显示位置和函数指针,将使得
: :       程序运算量有轻微增长;在刷新menu.ini的时候有可能造成某些用户
: :       操作失败(在主选单上),也有隐含的造成用户掉线的可能(估计可能
: :       性很小);如果menu.ini错误,有可能导致所有用户掉线(因为共享的
: :       缘故),这样站长无法在检测到menu.ini刷新错误的情况下用另外的
: :       窗口恢复。
: (以下引言省略...)
============================================================================
==
quickmouse.bbs@bbs.nju.edu.cn 于  Fri Dec 21 11:52:17 2001 提到:
【 在 allstar (满天星) 的大作中提到: 】
: 【 在 quickmouse (碰猫死翘翘) 的大作中提到: 】
: : build的时候需要malloc的,在从malloc的内存当中复制数据到shm的过程当中需要

: : 重定位指针。在主菜单上,按键之前就会定位好函数指针地址,如果按键以后发现

: : 刷新,那么会重头再定位一次且使用户按键失效;如果在判断没有刷新之后由于
: : 切换进程又发生刷新,最多是传给函数的参数出现错误,但是由于参数都是字符串

: : 变量,并且在sysconf_buf定长的最后用了NULL,应该不会出现越界访问问题
:                                              ~~~~~~~~
:            这可不能应该不会,万一出问题怎么办,考虑一下我的建议如何
:   反正你一屏就只有10几个菜单项,绝不会超过20个,浪费一点空间增加安全性
:   不是更好吗?这样就不用malloc了!
:            而如果你增加新功能,是肯定要重新编译系统的
: : 具体的代码我要整理一下才贴出来,改动比较大。
: (以下引言省略 ... ...)
如果你能够提出可能出现越界的情况,我就要修改方案,
指针指向一片字符串区域,并且区域最后一个字节是'\0',在什么情况下
会出现越界?本来程序当中就没有使用malloc,malloc仅仅在站长使用
shift+~的时候站长的那个进程才会malloc,并不会影响其他的进程。
实在不明白你的忧虑。
============================================================================
==
quickmouse.bbs@bbs.nju.edu.cn 于  Fri Dec 21 11:52:18 2001 提到:
【 在 zhch (zhch) 的大作中提到: 】
: 我觉得要改的话可以改大一点,不一定要和FB原来的menu.ini格式兼容。
: FB的menu.ini处理方法可以说是很复杂的,而且编程风格和其他部分有一些区别,
: 也许也是从其他地方移植过来的。
: menu.ini如果要放在shm里面,数据都采用定长格式可能会比较方便。函数指针
: 在bbs代码变化后可能发生变化,因此放在shm中没有什么意义,但可以初始化时
: 一次性给出吧,不一定每次都要重定位吧。
每一个进程的fptr函数指针不一定都指向同一个地址,所以每个进程需要
保存自己的函数指针,因为shm当中menuitem结构当中的fptr只能保存字符串
用于指针检索,因此,每次进入或者推出一层主菜单的时候需要根据字符串
将函数指针检索出来(重定位)
: 另外,menu.ini变大时,shm需要扩展长度你打算如何处理?可能得事先设个最大值。

这一点本来在fb当中就是有最大值的,原来是menuitem最大256项,sysvar最大256项
sysconf_buf最大10k,我在新的程序当中扩充到了256, 256和20k,应该是足够了
: 【 在 quickmouse (碰猫死翘翘) 的大作中提到: 】
: : 这几天狂写测试代码终于有了结果,由于对程序结构改动比较大,
: : 这里不给出源代码,仅给出一些相关信息。
: : 优势: 节省进程占用的内存,引入一组数据重组结构,占用600B,将原来
: :        menu.ini所占用的内存放入shm当中(典型占用10~20k不等),如果
: :        不计shm分摊到每个进程的占用数目,那么新方式占用内存的数目为
: :        原来的4%~15%;其次,用户可以不重新登陆就可以使用新的界面
: : 缺点:由于每次进入主选单时都需要重新定位显示位置和函数指针,将使得
: :       程序运算量有轻微增长;在刷新menu.ini的时候有可能造成某些用户
: :       操作失败(在主选单上),也有隐含的造成用户掉线的可能(估计可能
: :       性很小);如果menu.ini错误,有可能导致所有用户掉线(因为共享的
: :       缘故),这样站长无法在检测到menu.ini刷新错误的情况下用另外的
: :       窗口恢复。
: (以下引言省略 ... ...)
============================================================================
==
quickmouse.bbs@bbs.nju.edu.cn 于  Fri Dec 21 11:52:19 2001 提到:
【 在 zhch (zhch) 的大作中提到: 】
: 我觉得要改的话可以改大一点,不一定要和FB原来的menu.ini格式兼容。
: FB的menu.ini处理方法可以说是很复杂的,而且编程风格和其他部分有一些区别,
: 也许也是从其他地方移植过来的。
: menu.ini如果要放在shm里面,数据都采用定长格式可能会比较方便。函数指针
另外,由于menu.ini里面数据长度严重不一,菜单命令每个只有几个到十几个字节,
而屏幕界面往往是一屏的数据,定长结构不现实,还是定长结构当中用指针指向
变长数据灵活一些。就是需要重定位指针罢了。
: 在bbs代码变化后可能发生变化,因此放在shm中没有什么意义,但可以初始化时
: 一次性给出吧,不一定每次都要重定位吧。
: 另外,menu.ini变大时,shm需要扩展长度你打算如何处理?可能得事先设个最大值。

: 【 在 quickmouse (碰猫死翘翘) 的大作中提到: 】
: : 这几天狂写测试代码终于有了结果,由于对程序结构改动比较大,
: : 这里不给出源代码,仅给出一些相关信息。
: : 优势: 节省进程占用的内存,引入一组数据重组结构,占用600B,将原来
: :        menu.ini所占用的内存放入shm当中(典型占用10~20k不等),如果
: :        不计shm分摊到每个进程的占用数目,那么新方式占用内存的数目为
: :        原来的4%~15%;其次,用户可以不重新登陆就可以使用新的界面
: : 缺点:由于每次进入主选单时都需要重新定位显示位置和函数指针,将使得
: :       程序运算量有轻微增长;在刷新menu.ini的时候有可能造成某些用户
: :       操作失败(在主选单上),也有隐含的造成用户掉线的可能(估计可能
: :       性很小);如果menu.ini错误,有可能导致所有用户掉线(因为共享的
: :       缘故),这样站长无法在检测到menu.ini刷新错误的情况下用另外的
: :       窗口恢复。
: (以下引言省略 ... ...)
============================================================================
==
allstar.bbs@bbs.nju.edu.cn 于  Fri Dec 21 11:52:20 2001 提到:
你的菜单不是放在shm里吗?
如果主菜单有10项,其中的第一个子菜单如系统讨论区有8项
假如你这两片内存区是紧接着的
如果你的主菜单要加一项,
那么子菜单的开始位置指针是要往后移或者主菜单第一项的指针要移到另一个区域
在这一瞬间,可能会出现什么情况,你解释一下你的算法好吗?
【 在 quickmouse (碰猫死翘翘) 的大作中提到: 】
: 【 在 allstar (满天星) 的大作中提到: 】
: :                                              ~~~~~~~~
: :            这可不能应该不会,万一出问题怎么办,考虑一下我的建议如何
: :   反正你一屏就只有10几个菜单项,绝不会超过20个,浪费一点空间增加安全性
: :   不是更好吗?这样就不用malloc了!
: :            而如果你增加新功能,是肯定要重新编译系统的
: : (以下引言省略 ... ...)
: 如果你能够提出可能出现越界的情况,我就要修改方案,
: 指针指向一片字符串区域,并且区域最后一个字节是'\0',在什么情况下
: 会出现越界?本来程序当中就没有使用malloc,malloc仅仅在站长使用
: shift+~的时候站长的那个进程才会malloc,并不会影响其他的进程。
: 实在不明白你的忧虑。
============================================================================
==
quickmouse.bbs@bbs.nju.edu.cn 于  Fri Dec 21 14:53:06 2001 提到:
嗯,这样呀,呵呵,原来的fb的menu.ini是怎么组织到内存当中去的
还是怎么组织,我在这方面没有什么改变。只不过原来它是变长
结构,先开256项,再按照实际数目写入内存,现在改为定长256项。
晚上我来贴一下menu.ini的组织结构
【 在 allstar (满天星) 的大作中提到: 】
: 你的菜单参数不是放在shm里吗?
: 如果主菜单有10项,其中的第一个子菜单如系统讨论区有8项
: 假如你这两片内存区是紧接着的
: 如果你的主菜单要加一项,
: 那么子菜单的开始位置指针要往后移或者主菜单第一项的指针要移到另一个区域
: 在这一瞬间,可能会出现什么情况,你解释一下你的算法好吗?
: 我说的问题不是指你的字符串,而是你的菜单项定位,字符串是不会有问题的
: 但你保存菜单各项参数的结构可能出问题
: 【 在 quickmouse (碰猫死翘翘) 的大作中提到: 】
: : 如果你能够提出可能出现越界的情况,我就要修改方案,
: : 指针指向一片字符串区域,并且区域最后一个字节是'\0',在什么情况下
: : 会出现越界?本来程序当中就没有使用malloc,malloc仅仅在站长使用
: : shift+~的时候站长的那个进程才会malloc,并不会影响其他的进程。
: : 实在不明白你的忧虑。
============================================================================
==
allstar.bbs@bbs.nju.edu.cn 于  Fri Dec 21 14:53:07 2001 提到:
哦,我以为你把整个struct MENU都放到共享内存里了!看来我们互相说了半天废话:)
【 在 quickmouse (碰猫死翘翘) 的大作中提到: 】
: 嗯,这样呀,呵呵,原来的fb的menu.ini是怎么组织到内存当中去的
: 还是怎么组织,我在这方面没有什么改变。只不过原来它是变长
: 结构,先开256项,再按照实际数目写入内存,现在改为定长256项。
: 晚上我来贴一下menu.ini的组织结构
: 【 在 allstar (满天星) 的大作中提到: 】
: : 你的菜单参数不是放在shm里吗?
: : 如果主菜单有10项,其中的第一个子菜单如系统讨论区有8项
: : 假如你这两片内存区是紧接着的
: : 如果你的主菜单要加一项,
: : 那么子菜单的开始位置指针要往后移或者主菜单第一项的指针要移到另一个区域
: : 在这一瞬间,可能会出现什么情况,你解释一下你的算法好吗?
: : 我说的问题不是指你的字符串,而是你的菜单项定位,字符串是不会有问题的
: : 但你保存菜单各项参数的结构可能出问题
============================================================================
==
ecnegrevid.bbs@ytht.net 于  Fri Dec 21 15:53:15 2001 提到:
good idea
但是略为增加了负责性, 也可能引起不稳定
maybe mmap can do this?
when menu.ini is changed, we just unlink the image file and create a new one
.
【 在 quickmouse.bbs@bbs.nju.edu.cn 的大作中提到: 】
: 这几天狂写测试代码终于有了结果,由于对程序结构改动比较大,
: 这里不给出源代码,仅给出一些相关信息。
: 优势: 节省进程占用的内存,引入一组数据重组结构,占用600B,将原来
:        menu.ini所占用的内存放入shm当中(典型占用10~20k不等),如果
:        不计shm分摊到每个进程的占用数目,那么新方式占用内存的数目为
:        原来的4%~15%;其次,用户可以不重新登陆就可以使用新的界面
: 缺点:由于每次进入主选单时都需要重新定位显示位置和函数指针,将使得
:       程序运算量有轻微增长;在刷新menu.ini的时候有可能造成某些用户
:       操作失败(在主选单上),也有隐含的造成用户掉线的可能(估计可能
: ...................
--

--
↑㊣㊣  欢迎加入 SCUT FTP PROJECT !←──────────────┄ ╭─╮
│㊣                                                              ╭╯╭╯
│      ╰→立即获得 yourname.scutftp.wox.org并加入华工ftp搜索引擎╰╮╰╮
│↑    ╰→详细请见 http://scutftp.yeah.net telnet://aoao.dhs.org╭╯╭╯
┼┼→                                                            ╰─╯㊣
┼┼─────────────────→ 欢迎加入 SCUT FTP PROJECT ! ㊣㊣

※ 来源:.华南网木棉站 bbs.gznet.edu.cn.[FROM: 211.66.25.139]
--
※ 转寄:.华南网木棉站 bbs.gznet.edu.cn.[FROM: 202.96.144.222]
--
※ 转载:·荔园晨风BBS站 bbs.szu.edu.cn·[FROM: 192.168.0.146]


[回到开始] [上一篇][下一篇]

荔园在线首页 友情链接:深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店