axios并发 react
2010-12-08 09:46:00 dqzhangp 阅读数 958


概述

本文先从理论上介绍几种大并发服务器的设计模式,然后分析Darwin Streaming Server的实现,从而为更好的理解Darwin视频服务器或者设计自己的视频服务器提供技术上的积累。


并发设计模式

阻塞的IO方式效率极低,这里不予讨论。非阻塞的IO分成两种,分别是非阻塞同步IO和非阻塞异步IO,对应的,Reactor和Proactor是高性能并发服务器设计中常见的两种模式,Reactor用于同步IO,Proactor用于异步IO。

 

 

 

无论是Reator还是Proactor,都包含了时间分离器和时间处理器。在接下来的对于Darwin视频服务器的分析中会发现其中也包含了事件分离器和事件处理器。


Darwin流媒体服务器

来看一下DarwinStreamingServer的架构,是不是采用了前面描述的两个模式那。Darwin流媒体服务器是由父进程及其fork出来的子进程构成的,子进程就是核心服务器。父进程的职责就是等待子进程退出。如果子进程出错退出,则父进程就会fork一个新的子进程,从而保证视频服务器继续提供服务。核心服务器的作用是充当VOD客户端与服务器模块之间的接口,VOD客户端采用RTP和RTSP协议向服务器发送请求并接收响应,服务器模块负责处理VOD客户端的请求并向VOD客户端发送数据包。核心服务器通过创建四种类型的线程来完成自己的工作:

 

  1. 服务器的主线程(Main Thread)。这个线程负责检查服务器是否需要关闭、记录状态信息、打印统计信息。
  2. 空闲任务线程(Idle Task Thread)。空闲任务线程管理一个周期性的任务队列。任务队列有两种类型:超时任务和套接口任务。
  3. 事件线程(Event Thread)。事件线程负责侦听套接口事件,比如收到RTSP请求和RTP数据包,然后把事件传递给任务线程。 
  4. 一个或者多个任务(Task)线程。任务线程从事件线程中接收RTSP和RTP请求,然后把请求传递到恰当的服务器模块进行处理,把数据包发送给客户端。缺省情况下,核心服务器为每一个处理器创建一个任务线程。

其中的事件线程就是Reactor模式中的事件分离器,任务线程就是Reactor中的事件处理器。


参考资料

  1. Proactor和Reactor模式_继续并发系统设计的扫盲,http://www.cppblog.com/kevinlynx/archive/2008/06/06/52356.html
  2. QuickTime Streaming Server Modules Programming Guide。
  3. Douglas C. Schmidt, Reactor - An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events

axios并发 react 相关内容

2016-09-20 21:10:55 hello_bravo_ 阅读数 2377

Reactor释义"反应堆",是一种事件驱动机制,和普通函数调用的不同之处在于,Reactor逆置了事件处理流程,应用程序需要提供相应接口并注册到Reactor上,如果相应的时间发生,Reactor将主动调用应用程序注册的接口,这些接口又称为“回调函数”。


Reactor简单的描述,就是当一件事情到时间了,那么他会自动执行。


Reactor模式的优点:

(1)响应快,不必为单个同步时间所阻塞,虽然Reactor本身依旧同步

(2)变成相对简单,可以最大程度地避免复杂得多线程同步问题,而且避免了多线程/进程的切换开销。

(3)可扩展性,可以方便的通过增加Reactor实例个数来充分利用CPU资源

(4)可复用性,reactor框架本身与具体时间处理逻辑无关,具有很高的复用性


Reactor模式框架

(1)事件源

(2)Reactor框架

(3)多路复用机制

(4)事件处理程序



:::::::::::::::::::::事件源::::::::::::::::::::::::::::

Handle

linux上是文件描述符,Windows上就是Socket或者Handle了,这里统一称为"句柄集":程序在指定的句柄上注册关心的事件,比如I/O事件。



:::::::::::::::::::::事件多路分发机制(多路复用):::::::::::::::::::

event demultiplexer

程序首先将其关心的句柄(事件源)及其事件注册到event demultiplexer上:

当有事件到达时,这个函数通知事件就绪

程序收到通知后就可以在非阻塞情况下对事件进行处理了

libevent中使用结构体eventop进行了封装


:::::::::::::::::::::反应器::::::::::::::::::::::::::::

Reactor

事件管理的接口,内部使用event demultiplexer注册,注销事件:

在函数内运行时间循环,当有事件进入就绪,那就调用注册事件的回调函数处理事件

对应libevent中,就是event_base结构体。

一般反应器如果是类,会包含

int register_handle(Event_Handler* pHandler,int event);

int remove_handle(Event_Handler* pHandler,int event);

void handle_events(timeval *ptv);


:::::::::::::::::::::事件处理程序:::::::::::::::::::::::::
事件处理程序提供了一组接口,每个接口对应了一种类型的事件,供Reactor在相应的事件发生时调用,执行相应的事件处理,通常它会绑定一个有效的句柄。
在libevent中就是event结构体


个人理解就是:

Reactor模式首先通过event demultiplexer在事件源上注册自己关心的事件,并同时进行监控,当有事件到达时这个函数起到通知作用,总体通过反应器运用event demultiplexer循环监听是否有相应的事件发生,如果有,就调用相应的事件处理函数(我认为他是通过I/O复用机制实现的非阻塞,但这是我个人想法。。等我上课问老师后再给确定的)。




两种高效的并发模式
并发编程的目的是让程序"同时"执行多个任务,如果程序是计算密集的则没有优势,反而由于任务的切换使效率降低。但如果程序是I/O密集型的,比如经常读写文件访问数据库等,则情况就不同了。

//////////////////////////////////////////////////////////////////////////////////////半同步/半异步//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

在并发中:

“同步”指的是程序完全按照代码序列的顺序执行

"异步"指的是程序的执行需要由系统事件来驱动

半同步/半异步:

同步用来处理客户逻辑

异步用来处理I/O事件


异步线程监听到客户请求后,就将其封装成请求对象并插入请求队列中,请求队列将通知某个工作在同步模式的工作线程来读取并处理该请求对象。


半同步/半反应堆采用的是Reactor模式

主线程充当异步线程,他负责监听所有socket上的事件,然后工作线程睡眠在请求队列上,当有任务到来时他们将通过竞争获得任务的接管权。





//////////////////////////////////////////////////////////////////////////////////////领导者/追随者//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

领导者/追随者模式是多个工作线程轮流获得事件源集合,轮流监听,分发并处理事件的一种模式。

在任意时间点,程序都仅有一个领导者线程,它负责监听I/O事件。

而其他线程都是追随者,他们休眠在线程池中等待成为新的领导者。

当前的领导者如果检测到I/O事件,首先要从线程池中推选出新的领导者线程,然后处理I/O事件。

此时,新的领导者等待新的I/O事件,而原来的领导者则处理I/O事件,二者实现了并发。













//////////////////////////////////////////////////////////////////////////////////////半同步/半异步//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

在并发中:

axios并发 react 相关内容

2012-04-27 09:57:10 maikforever 阅读数 409
6.6.2008


Kevin Lynx


Proactor和Reactor都是并发编程中的设计模式。在我看来,他们都是用于派发/分离IO操作事件的。这里所谓的
IO事件也就是诸如read/write的IO操作。"派发/分离"就是将单独的IO事件通知到上层模块。两个模式不同的地方
在于,Proactor用于异步IO,而Reactor用于同步IO。


摘抄一些关键的东西:


"
Two patterns that involve event demultiplexors are called Reactor and Proactor [1]. The Reactor patterns 
involve synchronous I/O, whereas the Proactor pattern involves asynchronous I/O.
"


关于两个模式的大致模型,从以下文字基本可以明白:


"
An example will help you understand the difference between Reactor and Proactor. We will focus on the read 
operation here, as the write implementation is similar. Here's a read in Reactor:


* An event handler declares interest in I/O events that indicate readiness for read on a particular socket ;
* The event demultiplexor waits for events ;
* An event comes in and wakes-up the demultiplexor, and the demultiplexor calls the appropriate handler; 
* The event handler performs the actual read operation, handles the data read, declares renewed interest in 
  I/O events, and returns control to the dispatcher .


By comparison, here is a read operation in Proactor (true async):


* A handler initiates an asynchronous read operation (note: the OS must support asynchronous I/O). In this 
  case, the handler does not care about I/O readiness events, but is instead registers interest in receiving 
  completion events;
* The event demultiplexor waits until the operation is completed ;
* While the event demultiplexor waits, the OS executes the read operation in a parallel kernel thread, puts 
  data into a user-defined buffer, and notifies the event demultiplexor that the read is complete ;
* The event demultiplexor calls the appropriate handler; 
* The event handler handles the data from user defined buffer, starts a new asynchronous operation, and returns
  control to the event demultiplexor.


"


可以看出,两个模式的相同点,都是对某个IO事件的事件通知(即告诉某个模块,这个IO操作可以进行或已经完成)。在结构
上,两者也有相同点:demultiplexor负责提交IO操作(异步)、查询设备是否可操作(同步),然后当条件满足时,就回调handler。
不同点在于,异步情况下(Proactor),当回调handler时,表示IO操作已经完成;同步情况下(Reactor),回调handler时,表示
IO设备可以进行某个操作(can read or can write),handler这个时候开始提交操作。


用select模型写个简单的reactor,大致为:




 ///
class handler
{
public:
    virtual void onRead() = 0;
    virtual void onWrite() = 0;
    virtual void onAccept() = 0;
}; 


class dispatch
{
public:
    void poll()
    {
        // add fd in the set.
        //
        // poll every fd
        int c = select( 0, &read_fd, &write_fd, 0, 0 );
        if( c > 0 )
        {
            for each fd in the read_fd_set
            {    if fd can read
                    _handler->onRead();
                if fd can accept
                    _handler->onAccept();
            } 


            for each fd in the write_fd_set
            {
                if fd can write
                    _handler->onWrite();
            }
        }
    } 


    void setHandler( handler *_h )
    {
        _handler = _h;
    } 


private:
    handler *_handler;
}; 


/// application
class MyHandler : public handler
{
public:
    void onRead()
    {
    } 


    void onWrite()
    {
    } 


    void onAccept()
    {
    }
}; 






在网上找了份Proactor模式比较正式的文档,其给出了一个总体的UML类图,比较全面:






根据这份图我随便写了个例子代码:




 class AsyIOProcessor
{
public:
    void do_read()
    {
        //send read operation to OS
        // read io finished.and dispatch notification
        _proactor->dispatch_read();
    } 


private:
    Proactor *_proactor;
}; 


class Proactor
{
public:
    void dispatch_read()
    {
        _handlerMgr->onRead();
    } 


private:
    HandlerManager *_handlerMgr;
}; 


class HandlerManager
{
public:
    typedef std::list<Handler*> HandlerList; 


public:
    void onRead()
    {
        // notify all the handlers.
        std::for_each( _handlers.begin(), _handlers.end(), onRead );
    } 


private:
    HandlerList *_handlers;
}; 


class Handler
{
public:
    virtual void onRead() = 0;
}; 


// application level handler.
class MyHandler : public Handler
{
public:
    void onRead() 
    {
        // 
    }
}; 






Reactor通过某种变形,可以将其改装为Proactor,在某些不支持异步IO的系统上,也可以隐藏底层的实现,利于编写跨平台
代码。我们只需要在dispatch(也就是demultiplexor)中封装同步IO操作的代码,在上层,用户提交自己的缓冲区到这一层,
这一层检查到设备可操作时,不像原来立即回调handler,而是开始IO操作,然后将操作结果放到用户缓冲区(读),然后再
回调handler。这样,对于上层handler而言,就像是proactor一样。详细技法参见这篇文章。


其实就设计模式而言,我个人觉得某个模式其实是没有完全固定的结构的。不能说某个模式里就肯定会有某个类,类之间的
关系就肯定是这样。在实际写程序过程中也很少去特别地实现某个模式,只能说模式会给你更多更好的架构方案。


最近在看spserver的代码,看到别人提各种并发系统中的模式,有点眼红,于是才来扫扫盲。知道什么是leader follower模式,
reactor, proactor,multiplexing,对于心中的那个网络库也越来越清晰。


最近还干了些离谱的事,写了传说中的字节流编码,用模板的方式实现,不但保持了扩展性,还少写很多代码;处于效率考虑,
写了个static array容器(其实就是template <typename _Tp, std::size_t size> class static_array { _Tp _con[size]),
加了iterator,遵循STL标准,可以结合进STL的各个generic algorithm用,自我感觉不错。基础模块搭建完毕,解析了公司
服务器网络模块的消息,我是不是真的打算用自己的网络模块重写我的验证服务器?在另一个给公司写的工具里,因为实在厌恶
越来越多的重复代码,索性写了几个宏,还真的做到了代码的自动生成:D。


对优雅代码的追求真的成了种癖好.  = =|

转自 http://www.cppblog.com/kevinlynx/archive/2008/06/06/52356.html

axios并发 react 相关内容

2008-10-25 23:32:00 joliny 阅读数 1534

Proactor和Reactor都是并发编程中的设计模式。在我看来,他们都是用于派发/分离IO操作事件的。这里所谓的
IO事件也就是诸如read/write的IO操作。"派发/分离"就是将单独的IO事件通知到上层模块。两个模式不同的地方
在于,Proactor用于异步IO,而Reactor用于同步IO。

摘抄一些关键的东西:

"
Two patterns that involve event demultiplexors are called Reactor and Proactor [1]. The Reactor patterns 
involve synchronous I/O, whereas the Proactor pattern involves asynchronous I/O.
"

关于两个模式的大致模型,从以下文字基本可以明白:

"
An example will help you understand the difference between Reactor and Proactor. We will focus on the read 
operation here, as the write implementation is similar. Here's a read in Reactor:

* An event handler declares interest in I/O events that indicate readiness for read on a particular socket ;
* The event demultiplexor waits for events ;
* An event comes in and wakes-up the demultiplexor, and the demultiplexor calls the appropriate handler; 
* The event handler performs the actual read operation, handles the data read, declares renewed interest in 
  I/O events, and returns control to the dispatcher .

By comparison, here is a read operation in Proactor (true async):

* A handler initiates an asynchronous read operation (note: the OS must support asynchronous I/O). In this 
  case, the handler does not care about I/O readiness events, but is instead registers interest in receiving 
  completion events;
* The event demultiplexor waits until the operation is completed ;
* While the event demultiplexor waits, the OS executes the read operation in a parallel kernel thread, puts 
  data into a user-defined buffer, and notifies the event demultiplexor that the read is complete ;
* The event demultiplexor calls the appropriate handler; 
* The event handler handles the data from user defined buffer, starts a new asynchronous operation, and returns
  control to the event demultiplexor.

"

可以看出,两个模式的相同点,都是对某个IO事件的事件通知(即告诉某个模块,这个IO操作可以进行或已经完成)。在结构
上,两者也有相同点:demultiplexor负责提交IO操作(异步)、查询设备是否可操作(同步),然后当条件满足时,就回调handler。
不同点在于,异步情况下(Proactor),当回调handler时,表示IO操作已经完成;同步情况下(Reactor),回调handler时,表示
IO设备可以进行某个操作(can read or can write),handler这个时候开始提交操作。

用select模型写个简单的reactor,大致为:

///
class handler
{
public:
    
virtual void onRead() = 0;
    
virtual void onWrite() = 0;
    
virtual void onAccept() = 0;
}


class dispatch
{
public:
    
void poll()
    
{
        
// add fd in the set.
        
//
        
// poll every fd
        int c = select( 0&read_fd, &write_fd, 00 );
        
if( c > 0 )
        
{
            
for each fd in the read_fd_set
            
{    if fd can read
                    _handler
->onRead();
                
if fd can accept
                    _handler
->onAccept();
            }
 

            
for each fd in the write_fd_set
            
{
                
if fd can write
                    _handler
->onWrite();
            }

        }

    }
 

    
void setHandler( handler *_h )
    
{
        _handler 
= _h;
    }
 

private:
    handler 
*_handler;
}


/// application
class MyHandler : public handler
{
public:
    
void onRead()
    
{
    }
 

    
void onWrite()
    
{
    }
 

    
void onAccept()
    
{
    }

}



在网上找了份Proactor模式比较正式的文档,其给出了一个总体的UML类图,比较全面:

proactor_uml

根据这份图我随便写了个例子代码:

class AsyIOProcessor
{
public:
    
void do_read()
    
{
        
//send read operation to OS
        
// read io finished.and dispatch notification
        _proactor->dispatch_read();
    }
 

private:
    Proactor 
*_proactor;
}


class Proactor
{
public:
    
void dispatch_read()
    
{
        _handlerMgr
->onRead();
    }
 

private:
    HandlerManager 
*_handlerMgr;
}


class HandlerManager
{
public:
    typedef std::list
<Handler*> HandlerList; 

public:
    
void onRead()
    
{
        
// notify all the handlers.
        std::for_each( _handlers.begin(), _handlers.end(), onRead );
    }
 

private:
    HandlerList 
*_handlers;
}


class Handler
{
public:
    
virtual void onRead() = 0;
}


// application level handler.
class MyHandler : public Handler
{
public:
    
void onRead() 
    
{
        
// 
    }

}



Reactor通过某种变形,可以将其改装为Proactor,在某些不支持异步IO的系统上,也可以隐藏底层的实现,利于编写跨平台
代码。我们只需要在dispatch(也就是demultiplexor)中封装同步IO操作的代码,在上层,用户提交自己的缓冲区到这一层,
这一层检查到设备可操作时,不像原来立即回调handler,而是开始IO操作,然后将操作结果放到用户缓冲区(读),然后再
回调handler。这样,对于上层handler而言,就像是proactor一样。详细技法参见这篇文章

其实就设计模式而言,我个人觉得某个模式其实是没有完全固定的结构的。不能说某个模式里就肯定会有某个类,类之间的
关系就肯定是这样。在实际写程序过程中也很少去特别地实现某个模式,只能说模式会给你更多更好的架构方案。

最近在看spserver的代码,看到别人提各种并发系统中的模式,有点眼红,于是才来扫扫盲。知道什么是leader follower模式
reactor, proactor,multiplexing,对于心中的那个网络库也越来越清晰。

最近还干了些离谱的事,写了传说中的字节流编码,用模板的方式实现,不但保持了扩展性,还少写很多代码;处于效率考虑,
写了个static array容器(其实就是template <typename _Tp, std::size_t size> class static_array { _Tp _con[size]),
加了iterator,遵循STL标准,可以结合进STL的各个generic algorithm用,自我感觉不错。基础模块搭建完毕,解析了公司
服务器网络模块的消息,我是不是真的打算用自己的网络模块重写我的验证服务器?在另一个给公司写的工具里,因为实在厌恶
越来越多的重复代码,索性写了几个宏,还真的做到了代码的自动生成:D。

对优雅代码的追求真的成了种癖好.  = =|

axios并发 react 相关内容

2012-12-04 09:34:44 lionzl 阅读数 330

Proactor和Reactor模式_继续并发系统设计的扫盲

6.6.2008

Kevin Lynx

Proactor和Reactor都是并发编程中的设计模式。在我看来,他们都是用于派发/分离IO操作事件的。这里所谓的
IO事件也就是诸如read/write的IO操作。"派发/分离"就是将单独的IO事件通知到上层模块。两个模式不同的地方
在于,Proactor用于异步IO,而Reactor用于同步IO。

摘抄一些关键的东西:

"
Two patterns that involve event demultiplexors are called Reactor and Proactor [1]. The Reactor patterns
involve synchronous I/O, whereas the Proactor pattern involves asynchronous I/O.
"

关于两个模式的大致模型,从以下文字基本可以明白:

"
An example will help you understand the difference between Reactor and Proactor. We will focus on the read
operation here, as the write implementation is similar. Here's a read in Reactor:

* An event handler declares interest in I/O events that indicate readiness for read on a particular socket ;
* The event demultiplexor waits for events ;
* An event comes in and wakes-up the demultiplexor, and the demultiplexor calls the appropriate handler;
* The event handler performs the actual read operation, handles the data read, declares renewed interest in
  I/O events, and returns control to the dispatcher .

By comparison, here is a read operation in Proactor (true async):

* A handler initiates an asynchronous read operation (note: the OS must support asynchronous I/O). In this
  case, the handler does not care about I/O readiness events, but is instead registers interest in receiving
  completion events;
* The event demultiplexor waits until the operation is completed ;
* While the event demultiplexor waits, the OS executes the read operation in a parallel kernel thread, puts
  data into a user-defined buffer, and notifies the event demultiplexor that the read is complete ;
* The event demultiplexor calls the appropriate handler;
* The event handler handles the data from user defined buffer, starts a new asynchronous operation, and returns
  control to the event demultiplexor.

"

可以看出,两个模式的相同点,都是对某个IO事件的事件通知(即告诉某个模块,这个IO操作可以进行或已经完成)。在结构
上,两者也有相同点:demultiplexor负责提交IO操作(异步)、查询设备是否可操作(同步),然后当条件满足时,就回调handler。
不同点在于,异步情况下(Proactor),当回调handler时,表示IO操作已经完成;同步情况下(Reactor),回调handler时,表示
IO设备可以进行某个操作(can read or can write),handler这个时候开始提交操作。

用select模型写个简单的reactor,大致为:

///
class handler
{
public:
    
virtual void onRead() = 0;
    
virtual void onWrite() = 0;
    
virtual void onAccept() = 0;
}


class dispatch
{
public:
    
void poll()
    
{
        
// add fd in the set.
        
//
        
// poll every fd
        int c = select( 0&read_fd, &write_fd, 00 );
        
if( c > 0 )
        
{
            
for each fd in the read_fd_set
            
{    if fd can read
                    _handler
->onRead();
                
if fd can accept
                    _handler
->onAccept();
            }
 

            
for each fd in the write_fd_set
            
{
                
if fd can write
                    _handler
->onWrite();
            }

        }

    }
 

    
void setHandler( handler *_h )
    
{
        _handler 
= _h;
    }
 

private:
    handler 
*_handler;
}


/// application
class MyHandler : public handler
{
public:
    
void onRead()
    
{
    }
 

    
void onWrite()
    
{
    }
 

    
void onAccept()
    
{
    }

}



在网上找了份Proactor模式比较正式的文档,其给出了一个总体的UML类图,比较全面:

proactor_uml

根据这份图我随便写了个例子代码:

class AsyIOProcessor
{
public:
    
void do_read()
    
{
        
//send read operation to OS
        
// read io finished.and dispatch notification
        _proactor->dispatch_read();
    }
 

private:
    Proactor 
*_proactor;
}


class Proactor
{
public:
    
void dispatch_read()
    
{
        _handlerMgr
->onRead();
    }
 

private:
    HandlerManager 
*_handlerMgr;
}


class HandlerManager
{
public:
    typedef std::list
<Handler*> HandlerList; 

public:
    
void onRead()
    
{
        
// notify all the handlers.
        std::for_each( _handlers.begin(), _handlers.end(), onRead );
    }
 

private:
    HandlerList 
*_handlers;
}


class Handler
{
public:
    
virtual void onRead() = 0;
}


// application level handler.
class MyHandler : public Handler
{
public:
    
void onRead() 
    
{
        
// 
    }

}



Reactor通过某种变形,可以将其改装为Proactor,在某些不支持异步IO的系统上,也可以隐藏底层的实现,利于编写跨平台
代码。我们只需要在dispatch(也就是demultiplexor)中封装同步IO操作的代码,在上层,用户提交自己的缓冲区到这一层,
这一层检查到设备可操作时,不像原来立即回调handler,而是开始IO操作,然后将操作结果放到用户缓冲区(读),然后再
回调handler。这样,对于上层handler而言,就像是proactor一样。详细技法参见这篇文章

其实就设计模式而言,我个人觉得某个模式其实是没有完全固定的结构的。不能说某个模式里就肯定会有某个类,类之间的
关系就肯定是这样。在实际写程序过程中也很少去特别地实现某个模式,只能说模式会给你更多更好的架构方案。

最近在看spserver的代码,看到别人提各种并发系统中的模式,有点眼红,于是才来扫扫盲。知道什么是leader follower模式
reactor, proactor,multiplexing,对于心中的那个网络库也越来越清晰。

最近还干了些离谱的事,写了传说中的字节流编码,用模板的方式实现,不但保持了扩展性,还少写很多代码;处于效率考虑,
写了个static array容器(其实就是template <typename _Tp, std::size_t size> class static_array { _Tp _con[size]),
加了iterator,遵循STL标准,可以结合进STL的各个generic algorithm用,自我感觉不错。基础模块搭建完毕,解析了公司
服务器网络模块的消息,我是不是真的打算用自己的网络模块重写我的验证服务器?在另一个给公司写的工具里,因为实在厌恶
越来越多的重复代码,索性写了几个宏,还真的做到了代码的自动生成:D。

对优雅代码的追求真的成了种癖好.  = =|

posted on 2008-06-06 13:25 Kevin Lynx 阅读(15618) 评论(7)  编辑 收藏 引用 所属分类: 网络编程模块架构

评论

# re: Proactor和Reactor模式_继续并发系统设计的扫盲2008-06-06 15:13关中刀客

模式是个好东西,但不是绝对的好东西,有时也不是很必要使用proactor  回复  更多评论  

# re: Proactor和Reactor模式_继续并发系统设计的扫盲2008-06-06 15:40Kevin Lynx

@关中刀客
传说哥们和我同年同月差一天就同日生(我10号:d)

还有,一直想看下你的cobra是个什么东西  回复  更多评论  

# re: Proactor和Reactor模式_继续并发系统设计的扫盲2008-06-06 16:43关中刀客

To Kevin Lynx兄:
呵呵,有缘有缘,我的cobra_win是一个网络通讯库,主要是针对iocp,采用异步多线程,底层目前已经有了自己的一套内存管理策略,比较完善的日志模快,定时器模块等等,感觉对于底层来说,已经相对的完善了,现在需要做的就是多多的改进和修正很多东西。呵呵,以后可以多多的交流~  回复  更多评论  

# re: Proactor和Reactor模式_继续并发系统设计的扫盲2008-06-06 17:19Kevin Lynx

@关中刀客
难道不开源?不知道能否分享下代码。

我之前在google,baidu都搜索过你这个东西,没有发现类似googlecode之类的项目地址。。  回复  更多评论  

# re: Proactor和Reactor模式_继续并发系统设计的扫盲2008-06-11 14:15胡章优

写的很不错
这两个模式在服务器开发中是应用的最多的算是

另外一点开发的重点在集群管理上面

刀客的东西可能想商业化,并没有开源的打算  回复  更多评论  

# re: Proactor和Reactor模式_继续并发系统设计的扫盲[未登录]2008-06-12 19:25杨粼波

IOCP就是Proactor实现的系统级的事件分离器。

leader follower模式,是一种并发模式,也可以说是一种策略。
这些都可以在ACE的那两本网络编程的书里面看到讲解。
我最近一直看这书,一边写自己的网络库。之前写的不满意,现在重新写一个。尝试先用UML建模的方法。

axios并发 react 相关内容

没有更多推荐了,返回首页