Chinaunix首页 | 论坛 | 博客
  • 博客访问: 8032921
  • 博文数量: 594
  • 博客积分: 13065
  • 博客等级: 上将
  • 技术积分: 10324
  • 用 户 组: 普通用户
  • 注册时间: 2008-03-26 16:44
个人简介

推荐: blog.csdn.net/aquester https://github.com/eyjian https://www.cnblogs.com/aquester http://blog.chinaunix.net/uid/20682147.html

文章分类

全部博文(594)

分类: C/C++

2012-06-21 19:57:15

mooon的设计进入关键时刻,有几个决策点还没有定下来,如下:

1.是否同时支持进程和线程模型
进程模型是指内核为一个独立的进程,而每个业务又为独立的一个进程,业务可以为多线程,同时内核会产生相应个数的内核线程与业务线程一一对应,内核线程和业务进程在创建业务时产生。
线程模型是业务和内核运行在相同的进程中,内核线程即为业务线程,在创建业务时产生。

2.service和线程不绑定(即不建立亲和关系),而session和线程建立绑定关系是否合理?
这么做重要的原因是考虑效率和保持简单,service不绑定,可以保证随机调度,这样就可以在随机的线程中创建session,并由这个线程调度和管理session(创建和销毁);同时由于session只会被一个线程调度,会使得真对单个session的编程不需要考虑线程安全;另外,不同session运行在不同线程中,又可保证一定的并发性,但线程和session是一对多的关系,因为session数量允许超过10万个。

3.一个session是否要支持可以有子session,子session下是否还要有子session
这个主要是考虑多方会话和群组类需求。

4.如果父session和线程是绑定关系,那子session是否和父session绑定到相同的session?
这个主要影响到复杂度,最好是可以相同,但是否会影响实用性了?

目前的计划:同时支持线程和进程模型,并且对于同一节点的进程模型业务,会使用pipe通讯绕过网络,影响最大的是第4点。

孤独,希望可以看到更多的讨论,计划端午三天完成设计图。
阅读(1806) | 评论(5) | 转发(0) |
给主人留下些什么吧!~~

Aquester2012-06-27 11:33:21

wwwsq: 多线程的程序在fork的时候会有些麻烦。你把agent想的太复杂了。如果你的agent要部署到几万台机器的话,简单的东西才稳定。.....
fork是必要的,必须和业务隔离开来,否则稳定性没保证,出了问题关系也将扯不清。由于是一对一的模型,倒没有增加太多的复杂度,具体可以参见设计图。

wwwsq2012-06-27 09:55:41

多线程的程序在fork的时候会有些麻烦。你把agent想的太复杂了。如果你的agent要部署到几万台机器的话,简单的东西才稳定。

Aquester2012-06-22 16:04:25

zwctaszlh: 个人愚见
1. 一个业务至少一个进程;一个业务可以选择单线程或多线程(后期支持即可)。
2.一个线程对应一个session即可,如果多个session,业务比较复杂,可暂.....
呵呵,谢谢,同时支持进程和线程模型不会增加太多的复杂度,但一种肯定会简单些。另外多线程肯定是要支持的,并且不同service会运行在不再的线程池中。

zwctaszlh2012-06-22 14:09:50

个人愚见
1. 一个业务至少一个进程;一个业务可以选择单线程或多线程(后期支持即可)。
2.一个线程对应一个session即可,如果多个session,业务比较复杂,可暂不支持。
3.一个session 支持子session即可,多重子session,比较复杂,可暂不支持。
4.父子session 和2的比较矛盾,父子session 属于两个独立的线程,不要有强关联与复杂的数据交互,最好可提供数据同步接口。

mshrat2012-06-21 20:33:20

感觉子session用处不大,会在哪种场景中使用到?