第二人生的源码分析(四十三)虚拟文件系统线程

由于第二人生是一个3D显示的软件,因此它就需要不断地从服务器下载大量数据,比如纹理图片,不同的角色是使用不同的纹理图片来实现不同的衣服外表的。当显示这些角色时,就使用从服务器下载的纹理图片。如果显示的人物角色比较多,比如有30个人时,这些纹理图片就需要保存到磁盘里。那么怎么样保存到磁盘里呢?保存到磁盘里就需要一个好的文件系统来保存,以及读取数据出来。读写磁盘是一项比较慢的工作,因此需要使用一个线程来实现。还有时读写文件并不需要及时性的动作,可以让线程等到CPU空闲时再去做这些事情。

 

LLVFSThread类是继承LLQueuedThread类,这样LLVFSThread就变成消息循环处理类了。只需要不断地添加请求到消息队列里,然后再实现消息处理函数,就实现相应的功能了。

#001 //static

#002 void LLVFSThread::initClass(bool local_is_threaded)

#003 {

#004      llassert(sLocal == NULL);

#005      sLocal = new LLVFSThread(local_is_threaded);

#006 }

上面实始化虚拟文件系统线程类。

 

 

#001 LLVFSThread::handle_t LLVFSThread::read(LLVFS* vfs, const LLUUID &file_id, const LLAssetType::EType file_type,

#002                                                                     U8* buffer, S32

#003 offset, S32 numbytes, U32 priority, U32 flags)

#004 {

 

获取处理的句柄。

#005      handle_t handle = generateHandle();

#006 

 

获取这个请求的执行优先级。

#007      priority = llmax(priority, (U32)PRIORITY_LOW); // All reads are at least PRIORITY_LOW

 

创建读取数据请求消息。

#008      Request* req = new Request(handle, priority, flags, FILE_READ, vfs, file_id, file_type,

#009                                                   buffer, offset, numbytes);

#010 

 

添加这个消息到消息队列。

#011      bool res = addReq

时间: 2024-08-19 10:35:15

第二人生的源码分析(四十三)虚拟文件系统线程的相关文章

第二人生的源码分析(四十四)虚拟文件系统的请求处理

在虚拟文件系统的消息队列里,主要就是LLVFSThread::Request类的请求,Request类是嵌套类,定义在LLVFSThread类里面.它主要实现对类LLVFS的封装访问,让操作更加方便一些,当然它是继续QueuedRequest类的,这样才可以添加到消息队列里去,否则不能添加到这个消息队列容器,也不能实现请求处理的多态了.   下面是类Request的构造函数. #001 LLVFSThread::Request::Request(handle_t handle, U32 prio

JUnit源码分析(四)——从Decorator模式说起

其实我这系列小文,名为源码分析,其实是自己读<设计模式>的读书笔记.Decorator模式在java的IO库中得到应用,java的IO库看起来复杂,其实理解了Decorator模式再回头看可以很好理解并使用.     Decorator模式,也就是装饰器模式,是对象结构型模式之一. 1.意图:动态地给一个对象添加一些额外的职责.给对象添加功能,我们首先想到的是继承,但是如果每增一个功能都需要继承,类的继承体系将无可避免地变的庞大和难以理解.面向对象设计的原则:优先使用组合,而非继承,继承的层次

HDFS源码分析数据块复制监控线程ReplicationMonitor(一)

        ReplicationMonitor是HDFS中关于数据块复制的监控线程,它的主要作用就是计算DataNode工作,并将复制请求超时的块重新加入到待调度队列.其定义及作为线程核心的run()方法如下: /** * Periodically calls computeReplicationWork(). * 周期性调用computeReplicationWork()方法 */ private class ReplicationMonitor implements Runnable

第二人生的源码分析(三十一)接收数据的流量控制

数据接收回来后,本来就应立即处理掉,这样是比较简单的想法.但由于网络带宽有限,这时就需要限制UDP接收数据的速度.下面就来分析这种需求的实现,它的代码如下: #001 S32 LLPacketRing::receivePacket (S32 socket, char *datap) #002 { #003      S32 packet_size = 0; #004    下面判断是否使用接收的流量限制. #005      // If using the throttle, simulate

OkHttp 3.7源码分析(四)——缓存策略

OkHttp3.7源码分析文章列表如下: OkHttp源码分析--整体架构 OkHttp源码分析--拦截器 OkHttp源码分析--任务队列 OkHttp源码分析--缓存策略 OkHttp源码分析--多路复用 合理地利用本地缓存可以有效地减少网络开销,减少响应延迟.HTTP报头也定义了很多与缓存有关的域来控制缓存.今天就来讲讲OkHttp中关于缓存部分的实现细节. 1. HTTP缓存策略 首先来了解下HTTP协议中缓存部分的相关域. 1.1 Expires 超时时间,一般用在服务器的respon

jQuery 1.9.1源码分析系列(十四)之常用jQuery工具_jquery

为了给下一章分析动画处理做准备,先来看一下一些工具.其中队列工具在动画处理中被经常使用. jQuery.fn. queue(([ queueName ] [, newQueue ]) || ([ queueName ,] callback ))(获取或设置当前匹配元素上待执行的函数队列. 如果当前jQuery对象匹配多个元素:获取队列时,只获取第一个匹配元素上的队列:设置队列(替换队列.追加函数)时,则为每个匹配元素都分别进行设置.如果需要移除并执行队列中的第一个函数,请使用dequeue()函

jQuery 1.9.1源码分析系列(十三)之位置大小操作_jquery

先给大家展示谢 jQuery.fn.css (propertyName [, value ]| object )(函数用于设置或返回当前jQuery对象所匹配的元素的css样式属性值.如果需要删除指定的css属性,请使用该函数将其值设为空字符串("") 注意:1.如果省略了value参数,则表示获取属性值:如果指定了该参数,则表示设置属性值.2.css()函数的所有"设置"操作针对的是当前jQuery对象所匹配的每一个元素:所有"读取"操作只针对

vue2.0源码分析之理解响应式架构

分享前啰嗦 我之前介绍过vue1.0如何实现observer和watcher.本想继续写下去,可是vue2.0横空出世..所以 直接看vue2.0吧.这篇文章在公司分享过,终于写出来了.我们采用用最精简的代码,还原vue2.0响应式架构实现 以前写的那篇 vue 源码分析之如何实现 observer 和 watcher可以作为本次分享的参考. 不过不看也没关系,但是最好了解下Object.defineProperty 本文分享什么 理解vue2.0的响应式架构,就是下面这张图 顺带介绍他比rea

Epoll详解及源码分析【转】

  转自:http://blog.csdn.net/chen19870707/article/details/42525887 版权声明:本文为博主原创文章,未经博主允许不得转载.   目录(?)[-]   什么是epoll   Apache模型Process Per Connection简称PPC 和 TPCThread Per Connection模型 select模型 poll模型 epoll模型 Epoll API int epoll_createint size int epoll_c