项目主页：http://hv-a.com/lpmt/

麻雀虽小，五脏俱全，适用于小型的projection mapping的项目。

支持一台电脑投射多个平面，目前也支持连接多台投影仪，从功能上来看是支持投影拼接的。最喜欢的是mask功能，可以将平面上不希望投影的地方通过mask去掉。

由于在windows平台测试，很多功能不支持，有兴趣的朋友可以在linux下测试一下。

在说明中也支持kinect，以下是features摘录：

• up to 36 independent projection surfaces (remember you can use a solid black quad even as a mask)
• possible content: solid color, images, video, shared-videos, multiple live-cams, slideshows, smoothly changing solid colors, and more …
• customizable green-screen (chromakey) for video and live-cam sources
• horizontal and vertical flipping for image, video and live-cam content
• independent opacity settings for each content element
• customizable colorization for each content element
• several blending-modes for projection surfaces
• on-screen editable masks
• circular and rectangular crop-masking
• bezier-warping for projection on curved surfaces
• grid-warping, with user defined grid density
• spherize deformation preset
• realtime live-masking with Kinect
• customizable video speed and volume
• save/load project set to/from xml file
• syncronized start for video elements
• vertex snap function for adjacent quads
• cam snapshot background for rough positioning of projection surfaces
• customizable speed for slideshows and color transitions
• synced multi-projectors shows with adjustable edge-blending
• control and setup through a rich set of OSC messages, for more information about OSC with LPMT seehere
• support for MIDI control, with on-the-fly coupling of midi messages, gui controls and hotkeys
• Syphon support for frame-sharing on Mac OsX
• multi-camera support 

在Linux下如果安装Manual手册，则可以直接使用man ascii查看ASCII表。

ASCII(7)                                             Linux Programmer's Manual                                             ASCII(7)

NAME
       ascii - ASCII character set encoded in octal, decimal, and hexadecimal

DESCRIPTION
       ASCII is the American Standard Code for Information Interchange.  It is a 7-bit code.  Many 8-bit codes (such as ISO 8859-1,
       the Linux default character set) contain ASCII as their lower half.  The international counterpart of ASCII is known as  ISO
       646.

       The following table contains the 128 ASCII characters.

       C program '\X' escapes are noted.

       Oct   Dec   Hex   Char                        Oct   Dec   Hex   Char
       ────────────────────────────────────────────────────────────────────────
       000   0     00    NUL '\0'                    100   64    40    @
       001   1     01    SOH (start of heading)      101   65    41    A
       002   2     02    STX (start of text)         102   66    42    B
       003   3     03    ETX (end of text)           103   67    43    C
       004   4     04    EOT (end of transmission)   104   68    44    D
       005   5     05    ENQ (enquiry)               105   69    45    E
       006   6     06    ACK (acknowledge)           106   70    46    F
       007   7     07    BEL '\a' (bell)             107   71    47    G
       010   8     08    BS  '\b' (backspace)        110   72    48    H
       011   9     09    HT  '\t' (horizontal tab)   111   73    49    I

(以下略) 

最近php机器频繁出现过载后再也无法提供服务的现象，只要一有请求发过去，负责处理该请求的php进程就是cpu占用100%。本来的负载均衡策略是一旦某机器的php请求出现连接超时就将该机器的权重降低，发向该机器的请求概率就会降低，虽然有一定滞后效应，但是最终应该能够降压并且最后恢复服务，但是这个策略在最近突然失效了。出现这个情况之后无法发送什么请求到php-fpm都会cpu100%，即使请求的是一个空的php文件。于是猜想可能是eaccelerator造成的。

我们的Php-fpm的request_terminate_timeout设置的是5s，于是只要是有请求执行超过5s就会被php-fpm将执行进程干掉，在出问题的前后出现了大量的5s超时，初步猜想可能是因为eaccelerator的共享内存造成的，子进程被干掉时共享内存被写错了，导致所有请求过来都会出错，但是这解释不了新文件也会被卡住的问题，于是去看eacceleraotr的代码，发现如下代码

#define spinlock_try_lock(rw)  asm volatile("lock ; decl %0" :"=m" ((rw)->lock) : : "memory")
#define _spinlock_unlock(rw)   asm volatile("lock ; incl %0" :"=m" ((rw)->lock) : : "memory")

static int mm_do_lock(mm_mutex* lock, int kind) 
{
    while (1) {
        spinlock_try_lock(lock);
        if (lock->lock == 0) { 
            lock->pid = getpid();
            lock->locked = 1; 
            return 1;
        }    
        _spinlock_unlock(lock);
        sched_yield();
    }    
    return 1;
}

static int mm_do_unlock(mm_mutex* lock) {
    if (lock->locked && (lock->pid == getpid())) {
        lock->pid = 0;
        lock->locked = 0;
        _spinlock_unlock(lock);
    }
    return 1;
}

其中mm_mutex是指向共享内存的，也就是说eac用了共享内存来当作进程间的锁，并且使用的spinlock方式，那这样一来一切都能解释的通了。设想如下一种情况，某个进程拿到锁之后被php-fpm干掉了，它没有unlock，这样一来所有的php-fpm子进程都拿不到锁，于是大家就都在这个while(1)循环里卡死了。猜想有了，怎么去证实呢？原来的想法是直接去读那片共享内存，结果发现php时IPC_PRIVATE的，所以没办法读了。于是只能等到线上出问题后gdb上去看内存，今天终于有了确凿的证据

(gdb) p *mm->lock
$8 = {lock = 4294966693, pid = 21775, locked = 1}

这里可以看到内存已经被进程号为21775的进程拿到了，但事实是，这个进程在很早以前就已经被干掉了。

问题得到证实了，那么再回头看一下这个问题发生的条件

1、请求执行时间很长，长到会被php-fpm干掉

2、进程被干掉时，php正在require文件，并且eac拿到了锁

从这里可以看到，有一些特定情形会将这个概率放大

1、request_terminate_timeout时间很短

2、使用auoload方式，或者在执行逻辑里require文件，因为如果在请求开始前就将所有的文件加载，那除非光require文件就已经超时，否则不应该会在require文件时被干掉。但是同样的使用autload方式也有一个比较丑陋的办法可以避过这个问题，那就是在autload函数里判断一下，如果执行时间过长了就直接exit而不是require

个人觉得，解决这个问题的最好办法是request_terminate_timeout时间设置的足够长，比如30s， 300s，而将超时判断全部放在应用层，不能通过php-fpm来处理这种问题，php-fpm事实只能用作最后一重保险，不得不使用的保险。另外php里还有一个超时设置max_execution_time，但是这个超时在cgi模式下是cpu时间，所以作用不大