PHP Intl扩展线程安全吗? [英] Is the PHP Intl extension thread safe?

查看:110
本文介绍了PHP Intl扩展线程安全吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我一直在阅读有关PHP语言环境的信息,看来setlocale()在线程方面有问题. (我对线程不太熟悉-文档提到它不是线程安全的)

I've been reading about locales in PHP and it seems setlocale() has problems with threads. (I'm not too familiar with threads - the docs mention it is not thread safe)

我想让我的项目能够处理某些数字格式,而Intl扩展名似乎很有趣.

I'd like to give my project the ability to deal with certain number formats and the Intl extension seems interesting.

http://php.net/manual/zh/book.intl.php

我应该期待与setlocale()使用Intl扩展名一样的问题吗?

Should I expect the same problems that setlocale() has using the Intl extension?

推荐答案

好,我自己也对此很好奇,所以我设计了一个测试.

Ok, I was curious about this myself as well, so I devised a test.

首先,我用以下两个文件测试了setlocale():

First I tested setlocale() with these two files:

<?php
# locale1.php
error_reporting( E_ALL | E_STRICT );

date_default_timezone_set( 'Europe/Amsterdam' );
setlocale( LC_ALL, 'dutch_nld' ); // awkward Windows locale string

sleep( 10 ); // let's sleep for a bit here

echo strftime( '%A, %B %d, %Y %X %Z', time() );

<?php
# locale2.php
error_reporting( E_ALL | E_STRICT );

date_default_timezone_set( 'America/Los_Angeles' );
setlocale( LC_ALL, 'english_usa' ); // awkward Windows locale string

echo strftime( '%A, %B %d, %Y %X %Z', time() );

然后,我在两个单独的选项卡中执行了它们.第一个locale1.php,在设置区域设置后会休眠10秒钟,这使我们有时间同时执行locale2.php.

Then I executed them in two seperate tabs. First locale1.php, that sleeps for 10 seconds after setting the locale, giving us time to execute locale2.php in the meanwhile.

令我惊讶的是,甚至不允许locale2.php正确更改语言环境. locale1.php中的sleep( 10 )似乎以不允许locale2.php同时更改语言环境的方式劫持了Apache/PHP进程.当然,它会 呼应日期,只是没有按照您的期望进行本地化.

To my surprise locale2.php isn't even allowed to change the locale correctly. It appears sleep( 10 ) in locale1.php hijacks the Apache/PHP process in such a way that it doesn't allow locale2.php to alter the locale in the meanwhile. It does however echo the date in the meanwhile of course, just not localized as you'd expect.

:抱歉,将其删除.似乎locale2.php 确实更改了语言环境,并且locale1.php然后在睡觉后打印英语日期而不是荷兰语.因此,确实似乎与setlocale()中的预期行为一致. /编辑

sorry, scrap that. It appears locale2.php does change the locale and locale1.php then prints the English date in stead of Dutch after sleeping. So that does appear to be in accordance with what is expected behavior from setlocale(). /Edit

然后,我用以下两个文件测试了IntlDateFormatter:

Then, I tested IntlDateFormatter with these two files:

<?php
# locale1.php
error_reporting( E_ALL | E_STRICT );

$dateFormatter = new IntlDateFormatter(
    'nl_NL',
     IntlDateFormatter::FULL,
     IntlDateFormatter::FULL,
     'Europe/Amsterdam'
);

sleep( 10 ); // let's sleep for a bit here

echo $dateFormatter->format( time() );

<?php
# locale2.php
error_reporting( E_ALL | E_STRICT );

$dateFormatter = new IntlDateFormatter(
    'en_US',
     IntlDateFormatter::FULL,
     IntlDateFormatter::FULL,
     'America/Los_Angeles'
);

echo $dateFormatter->format( time() );

,然后在两个单独的选项卡中再次执行它们,与使用第一组文件的方式相同.这确实给出了预期的结果:locale1.php处于睡眠状态时locale2.php根据美国规则很好地以美式英语打印日期,之后locale1.php根据荷兰语很好地以荷兰语打印日期规则.

and then executed them again in two separate tabs, the same way as with the first set of files. This does give the expected results: while locale1.php is sleeping locale2.php nicely prints a date in American-English according to American rules, after which locale1.php nicely prints a date in Dutch according to Dutch rules.

因此,最后,看来Intl对于该setlocale问题是安全的.

So, concluding, it appears Intl is safe from that setlocale problem.

但是请记住金yun敏的答案.由于缺乏使用Intl的经验,我无法对此发表评论.我最近才发现Intl.

But also mind Hyunmin Kim's answer of course. I couldn't comment on that, due to lack of experience with using Intl. I only recently discovered Intl.

这篇关于PHP Intl扩展线程安全吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆