我喜欢Ruby的原因

嘿嘿，继续露怯，咱们继续科普。首先你的逻辑思维能力有问题。我说你根本不懂mod_ruby，你回复说我说，你有本事给我多线程部署mod_rails来跑。请问我的帖子是如何推导出来你的回贴的？你给我讲讲中间的逻辑推导关系？

其次，我多次强调Rails不是线程安全的，这就是说Rails不能以多线程方式运行(PHP也是这样的)。但是很遗憾，明显我白白给你科普了这么久，Rails/PHP不能以多线程方式运行这个基本概念还是没能灌输到你的榆木脑袋里面，于是你又说出了“部署一个多线程的ror给我们看看，ruby的线程安全是真么表现出比php的优势的！”这种无知的话。真是无知者无畏阿。

不过关于mod_rails的话题，我还是有兴趣回答一下的，我才刚刚研究过mod_rails，并且写了篇博客来介绍mod_rails，你有兴趣可以到我的博客去看。

mod_rails和mod_php5的运行机制完全两码事，mod_php5的机制是把PHP解释器加载在Apache的进程里面运行的，所以此时Apache不应该以多线程方式运行；但是mod_rails的机制并不是这样，而是自己启动若干ruby管理进程，由这些管理进程来控制更多的Rails进程的启动，Rails进程和Apache之间通过Unix Socket通讯，因此在这张情况下，Apache用多进程跑也罢，用多线程跑也罢，都无所谓。

要说脸皮厚者真是莫过于此。自己都漏洞百出，连ruby基本概念，进程线程概念，PHP的部署，CGI方式等等统统压根不懂，还真是拿无知当有趣，不过的确有趣的很，逗逗你们，看你们暴露出一个又一个无知的常识性错误，我觉得很娱乐。嘿嘿，不过我也就今天有空，明天就没空逗你们玩了。

liusong1111 只是想说明一下闭包用于事务管理（例如这里就是确保数据库关闭）是很方便的....怎么说着说着又扯的这么远了?

资源回收如果靠操作系统来完成毕竟有很多局限（例如有些资源回收要求一定顺序，或者有些资源操作系统无法自动回收），而编程语言如果提供了相应的设施，自然更加灵活好用了。操作系统回收资源一般就当作最后一道盾牌来“收尸”。

我说robbin啊robbin啊，我只是想让你就下面的话认个小小的错:



我已重复了好多次啦，我跟你讨论的是“数据库连接是否能正常关闭的问题”，
你一看到“an instance of the PHP interpreter”被PHP的官方网站翻译成了“一个 PHP 解释器线程”，就断定我连PHP，线程，进程这些概念都一团浆糊，又没细看我的所有回复又在那乱说我们的PHP系统如何如何。

我只是引用官方网站的话，连英文版的我都没看到，难道引用别人的话还要去修改，
而且你找来的英文版的时间是：Fri, 25 Apr 2008，而中文版的时间是：Sun, 25 Nov 2007
英文版的时间明显比中文版的新。

你自己都把“an instance of the PHP interpreter”翻译成了“一个PHP解释器进程实例”，你还要去计较别人翻译错了！


我说


是间接告诉你，请你不要再跟我说教啦，就你目前的水平还远远不到给我科普的层次，
至于Ruby/Rails吗，也先请robbin给你的粉丝或JavaEye的管理员下道圣旨:不要再乱删我的回贴，
我还没炮轰Ruby/Rails呢，就被删了两贴了。

还有，我再告诉你我们的系统还在用，用得好好的，OCILogOff从没出过问题，
我再告诉你，亿阳信通这么个垄断性质的上市公司早已放言要替换我们的系统，
但是3年过去啦，我们的系统还没被替换，还在用，你知道为什么吗？不是因为PHP有多强，
而是因为我用Java开发的爱立信BSC网元告警系统目前无法取代，
很多PHP开发的系统只是构建在爱立信BSC网元告警系统上面，这些系统虽然数据库表多，代码也多，
但不要求高并发，也不用考虑负载问题，这些用PHP写的web层次的系统很次要，顶多是个配角。
说难听点我对web开发很不屑。

好啦，以后不会再谈论任何关于以前公司的事情，各位也不用费心思琢磨我到底是谁。


再强调一次，我跟你讨论的是“数据库连接是否能正常关闭的问题”。



最后，请到网上找个2004年前的php.tar.gz文件，解压后，找到ext/oci8这个目录，在目录下打开oci8.c文件

我已不想让你认错啦，我要发段oci8.c文件中的源代码让你马上不再说话。

/* {{{ proto bool ocilogoff(int conn)
   Disconnect from database */

PHP_FUNCTION(ocilogoff)
{
#if 0
	this function does nothing any more. server-connections get automagiclly closed on 
	request-end. connection handles will "dissappear" as soon as they are no longer 
	referenced. as this module makes heavy use of zends reference-counting mechanism
	this is the desired behavior. it has always been a bad idea to close a connection that
	has outstanding transactions. this way we have a nice-clean approach.
	(thies@thieso.net 20000110)

	oci_connection *connection;
	zval **conn;

	if (zend_get_parameters_ex(1, &conn) == FAILURE) {
		WRONG_PARAM_COUNT;
	}

	OCI_GET_CONN(connection,conn);

	connection->is_open = 0;

	zend_hash_apply(list, (apply_func_t) _stmt_cleanup TSRMLS_CC);

	if (zend_list_delete(connection->id) == SUCCESS) {
		RETURN_TRUE;
	} else {
		RETURN_FALSE;
	}
#endif
}

各位，我不了解PHP，不过这里谈的是语言特性在实现一些功能时是否很有意义，就数据库连接这个问题，ruby的伪代码估计就是：

def do_something
  @db = conn_to_db()
  if @db
    begin 
      yield @db
    ensure
      close_db_conn(@db)
    end
  end
end

do_something do |db|
  ....
end

那么，在do_something后面跟的那个闭包里面，如果有意外发生导致中途退出，则数据库连接会确保被正确关闭。

或者以下这种按需关闭的：

def do_something
  begin
    yield
  ensure
    close_db_conn(@db) if @db
  end
end

do_something do
  ...
  @db = conn_to_db()
  ...
  @db = nil if close_db_conn(@db)
  ...
end

其实这里确保资源回收的是begin...ensure...end机制，闭包只是使这种机制可以很好的被包装起来，使用时更加方便而已。

那么如果PHP有类似begin...ensure...end的机制，当然可以实现类似的回收资源，但是如果缺少闭包功能（或者函数不是一等公民）的话，实现起来不免就罗嗦了。

至于那个考操作系统回收资源(通过关闭socket)来关闭数据库，应该不是最佳选择。再者，如果以多线程方式运行，操作系统进程级别回收资源的机制就不会发生作用，例如线程中打开的socket不会被自动销毁。

另外，一个脚本语言的实现是否是“线程安全”的，要看在一个进程中是否允许多个实例，每个实例是否拥有单独的状态机，例如lua就是线程安全的。从C ruby的api来看，是不具备“线程安全”这个条件的。还请对C ruby实现有研究者来谈谈。

一个小小的建议,这帖锁了吧,语言之间爱恶的讨论,便如宗教之争,何必呢.

没有宗教信仰的人，当然无所谓宗教之争。

无心研究语言特性的人，自然无需参与此贴，一边看着就行，何必来此说风凉话呢？

我使用C/C++很有一段时间了也曾有“用什么语言无所谓”的想法。可最近两年想法逐渐改变，认为语言特性对软件开发的许多方面会产生深远影响，而讨论这种影响，以及为什么会有这种影响都不是没有意义的事。

即使严肃的讨论最终不幸被口水淹没，也希望大家能够保持清醒的头脑，否则JE就和CSDN没什么两样了。

行，我标明自己的语言立场是ruby。
但帖子里某些“讨论”近乎人身攻击，哪来清醒这两个字？