Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77720
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <472D9D28-4AD7-4B98-BBEE-A613F7FCA996@golemon.com>
References: <CAFp73Xv_bhs5zhA-7Fr4wchiEMCA76a9qMiSQA77CVf9-PnseA@mail.gmail.com>
 <472D9D28-4AD7-4B98-BBEE-A613F7FCA996@golemon.com>
Date: Tue, 30 Sep 2014 15:56:33 -0400
Message-ID: <CAFp73XtNLwpk3z=spnQa6KBJRj3MhA20uGXk03bzxvWgGZJSxA@mail.gmail.com>
To: Sara Golemon <php@golemon.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bd76b98ebc22105044dc8b6
Subject: Re: [PHP-DEV] [RFC] Move pecl_sync to core
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--047d7bd76b98ebc22105044dc8b6
Content-Type: text/plain; charset=UTF-8

> Fix the title? :)  Is it for sync or pecl_http?

Someone already fixed that.

> Isn't this extension a bit "young" to join php core ?

I agree. However, there's no equivalent existing support in PHP atm.
Also, any new functionality introduced to PHP would always be new, young
and caring maturity.

> What are the actual benefits of this being included in core? The RFC
> doesn't really list any.

I updated the RFC to include some rationale around it.

> Also, there was a discussion in June (started by Julien) about
> refactoring PHPs IO layer, where many people expressed a wish to have
> something libuv based in core, this comes with cross-platform
> semaphors and mutexes as well as a TON of other awesome goodies. If
> anything, this is what I would prefer in core.

I would love that, because it would make this RFC obsolete IF the low level
API also gets exposed to userland.
But if I/O gets refactored we have 2 alternatives:
- Locking is built-in concurrency intensive places, such as file creation,
writing, cache inclusion, etc.
- Low level API gets exposed to consumers, then any extension or userland
code could benefit

> Why would you use PHP for such low level concepts ?

I think I was able to answer that through the rationale section exposing an
example on RFC.
Please reply back if not.

> Why would we support it in Core?
> Why is this good for PHP?

PHP doesn't offer an easy cross-platform way to implement locking.
All you can do is through flock emulating Mutexes and Semaphores, but even
this is not cross-platform; for example, Windows does not support blocking
until it acquires the lock.

> Why will a significant percentage of users be interested in this?
> Why is it necessary?

Not a significant percentage would use it at userland level, I agree.
However, low level libraries could benefit that would later benefit many
other projects and people.
I, for example, would consider to add locking support inside of
Doctrine\Cache, which would benefit Zend, Symfony, Drupal, CMSs and many
other projects that rely on this low level abstraction API. But currently,
I'm unable to do it since there's no PHP support and also because we avoid
enforcing the necessity of PECL extensions to get code up and running.

PHP is not a toy language anymore and more robust functionality is severely
needed to the language move forward. I consider Locking is one of the
missing pieces to the language, but the world is not made of Guilherme
Blanco's... =P


PS: I'll answer Thomas' email later.


On Tue, Sep 30, 2014 at 1:27 PM, Sara Golemon <php@golemon.com> wrote:

> This needs a "Why" section.
>
> Why is this good for PHP?
> Why will a significant percentage of users be interested in this?
> Why is it necessary?
>
> This feel pretty niche to me.
>
> -Sara
>
> > On Sep 30, 2014, at 4:06, "guilhermeblanco@gmail.com" <
> guilhermeblanco@gmail.com> wrote:
> >
> > Hi,
> >
> > Here is a new RFC: https://wiki.php.net/rfc/sync
> >
> > Thoughts appreciated.
> >
> > Cheers,
> >
> > --
> > Guilherme Blanco
> > MSN: guilhermeblanco@hotmail.com
> > GTalk: guilhermeblanco
> > Toronto - ON/Canada
>



-- 
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

--047d7bd76b98ebc22105044dc8b6--