SEDA源码解读(三)



本篇,我们继续来看看seda的开源项目sandstorm,这次我们主要关注aDisk包的实现:



                       

AFile-通过上一篇我们对SimpleSink的介绍可以看出这是一个对于队列“槽端”的实现,事实上你会发现它并没有真正提供实现,这是一个文件对外的异步访问接口。既然它实现了SinkIF(因为SimpleSink实现了该接口,所以被其继承),那它就可以入队所有对于某一文件的特定请求。

AFileImpl-该类是一个内部类,只提供了包级别的访问权限,它表示了对于AFile的“实现”。这里实现之所以加引号,意思是这里并没有提供真正的实现,它其实还是一个抽象类,定义了一些接口方法而已。真正的实现类会继承该抽象类。

AFileTPImpl-它就是真正的实现类,继承自AFileImpl,它内部有一个队列用来存储事件。并且它使用一个线程池在文件上执行阻塞的I/O。从图上可以看到它同时还实现了QueueElementIF接口,说明它可以是一个事件。

备注从图上可以看到AFile与AFileImpl都继承了SimpleSink,而AFileTPImpl继承自AFileImpl。感觉关系有些乱了。我之前看也是这么认为,但仔细看了之后,其实会发现,还是有些合理的。AFile是一个文件对外的“接口”,包含了对于文件的操作,这些方法内部都是调用了AFileImpl的实现者处理的,而具体调用哪个实现者并不是它关系的问题,应该由管理器来负责。这里共同的目的都是为了保证AFile的简单,纯粹以及内部实现的可扩展性。

下面列出了,对于文件操作的一系列事件:

这里有两个抽象的事件基类:AFileRequest、AFileCompletion,他们都实现了QueueElementIF接口。

先介绍一下这两个抽象事件基类:

AFileRequest-它代表I/O请求的抽象基类,能够入AFile的enqueue()方法。

AFileCompletion-它表示I/O完成事件的抽象基类

AFileRequest的派生类:

AFileReadRequest-表示文件的读请求;

AFileWriteRequest-表示文件的写请求;

AFileFlushRequest-对于一个给定的文件,flush所有的I/O 事件

AFileSeekRequest-对于一个给定位置的给定文件,的查找事件

AFileCloseRequest-关闭一个给定的文件要触发该事件

AFileCompletion的派生类:

AFileIOCompleted-完成事件包括了对于之前的一个I/O请求已经完成

AFileIOExceptionOccurred-该完成事件包括在引发I/O请求时产生的IOException

AFileIOExceptionOccurred-一个在给定的文件上执行I/O操作但已经到达EOF位置的完成事件

AFileTPEventHandler-它是一个事件处理器(实现了EventHandlerIF),用来被AFileTPImpl层调用

AFileTM-内部抽象类,它用来表示一个AFile的线程管理器

AFileTPStageWrapper-它是AFileTPImpl的包装实现,实现了StageWrapperIF。(事实上该StageWrapper并没有一个真实的事件队列,AFileTPTM创建的线程将给予每个AFile提供队列)

AFileTPTM-它继承了TPSThreadManager,同时实现了ThreadManagerIF以及ProfilableIF接口。

(注:TPSThreadManager同样实现了ThreadManagerIF接口,它提供了每个stage,每个source有一个线程池的线程管理器)。它是一个为AFileTPImpl提供的ThreadManager,它管理一个用来在磁盘文件上执行阻塞I/O的线程池。

AFileMgr-它是一个内部类,用来给Sandstorm运行时和aDisk类库之间提供一个访问接口。应用程序不应该使用该类。

其实,作为磁盘I/Ostage的实现,它基本包含了对几个核心package的实现(api/api.internal)。它们大致的对应关系如下图所示:
                



版权声明:本文为博主原创文章,未经博主允许不得转载。