线程池 应用于 请求

现在fuse提供了10个线程。一般情况下这个已经足够了。但是如果我们进行大规模的复制或其他操作。可能就需要在这里等待。可以考虑增减fuse 线程，或者自己使用线程池来调用任务。我们首先讨论这两种方案的可行性。
1、fuse 为什么限定线程池的使用，没有清楚的原因。这样不清楚的改动，可能不好。而且如果你内核本身是
放置在系统中的。这样的改动显得不合理。
2、线程池的应用。要知道哪些操作请求可以应用于此。需要远程访问的有哪些可以应用于此。内容的读写？

3、如果采用多线程。那么在一些有关联的操作之间就需要建立起同步机制。如一个文件如果还没有传输完毕。那么是不能够进行下一次传输。这里是一个难点。要清楚的表述出来。
  
4、线程池本身的设计要素。线程池设计是一个技术方案。综合了一些技术，线程，队列，同步机制。
   线程池可以处理固定的读写请求。也可以把操作也设计为可选择的。这个对性能不会有什么影响。
   但是提供了很大的扩展空间。网络传输是我们要独立出来的。优化的是这样一种情形。我们写完了
   数据，应用fuse线程来传输。这样就少了一个线程去响应新的请求。如果我们采用队列形式，可以用
   20个线程来处理所有的这种操作。而有的操作本身又是需要时间的，在我们网络访问以外，还有需要
   处理的部分。这样我们可以把时间错开。如果我们线程池本身大于请求响应线程。那么就可以处理更多
   的请求。

5 全局通信问题:现有的结构下，没有固定的结构是让我们修改的，我们处理的对象是临时对象，如果我们
加入了线程池，那么一个对象应该记录这个文件的状态。采用现有的filemap 结构，文件如果遭遇其他操作，删除，改名，需要等到该文件处理完毕。 这个是极特殊的情况。在进行该类操作时，进行判断即可。
 

6 多线程方案的优势状况：复制多个文件。文件每个的写是不相关的，这样我们可以提高写入的最大并发，
  是加法，如果我们采用20个的线程池，那么就把并发提高到了10+20.当然要考虑到系统的整体带宽。要
  保证不浪费系统带宽。而且我们增加的线程主要来做写操作，那么fuse 自身的10个可以处理其他创建、
  读取目录的请求。这些不能放到增加线程中，因为需要保证顺序。系统知道这些顺序。
  劣势状况：文件之间相关的操作。读、写。目录结构改变。

7 线程之间锁： 线程池内部是有锁的。但是我们任务执行外是无锁的环境。那么就可以放心的在任务执行内部放置锁。

8 任务的具体确定。我们现在要把传输文件到服务器这块设置成为任务。它有准备工作和收尾。具体哪个部分。文件对象的处理