Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#38316 closed request (fixed)

php54 port missing sysv extensions

Reported by: bas@… Owned by: ryandesign (Ryan Schmidt)
Priority: Normal Milestone:
Component: ports Version: 2.1.3
Keywords: sysv, sysvmsg, sysvsem, sysvshm Cc: mantas@…, unwiredbrain@…
Port: php54

Description

In PHP ports prior to PHP 5.4 the sysv extensions (sysvmsg, sysvsem, sysvshm) are available. It seems that in the php54 port, these extensions are missing. They are neither compiled into the internal php binary nor available as variant or standalone php extension.

Since some of my projects rely on shared memory and message queueing using sysv, it would be great to have this functionality available in php54.

Change History (11)

comment:1 Changed 7 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… removed
Milestone: MacPorts Future
Owner: changed from macports-tickets@… to ryandesign@…
Status: newassigned

You're talking about the +ipc variant that the php5 port has, which enables these four configure flags:

        --enable-shmop \
        --enable-sysvsem \
        --enable-sysvshm \
        --enable-sysvmsg

You're right that I haven't made a port to correspond to this variant for the new php53/php54/php55 ports. Partly this is because I wasn't familiar with what these options do and so wasn't clear whether these four options should continue to be bundled together or whether they should become two or more separate ports. Do you have an opinion on that? I may have also run into some build problems but I don't remember; it was a few years ago that I last looked into this.

comment:2 Changed 7 years ago by ryandesign (Ryan Schmidt)

bas, can you provide guidance on the above? I need to know what users expect: are the sysvsem, sysvshm, sysvmsg and shmop extensions always used in concert, or do users sometimes use one without the others? Should I package them together or separately? Probably one reason they were bundled into a single variant in the old php5 port is that it is bad to have a port with too many variants, but there's no problem with having lots of little unrelated extension ports. I am currently considering making two ports—php-shmop and php-sysv—unless you say all four extensions are always used together and should all be in one port.

comment:3 in reply to:  2 Changed 7 years ago by bas@…

Replying to ryandesign@…:

bas, can you provide guidance on the above?

I'll be glad to.

sysvshm and shmop extensions are basically wrappers around the *nix System V IPC shared memory subsystem. They basically wrap the same low level functions, but differ in level of abstraction. The sysvshm extension uses a proprietary format for storing and reading shared memory blocks, which makes it impossible to use IPC shared memory blocks created by external non-PHP processes. The shmop extension is more low level, allowing you to store and read raw data into a shared memory block.

sysvsem extension basically implements System V semaphores. Frequently used for establishing critical paths in a multithreaded environment. PHP does not support native multithreading, but with forking it is possible to have multiple threads active, albeit in different processes.

sysvmsg extension implements System V message queuing. It exposes functions to create and delete a queue and push / pop messages on the queue.

Typically, all of the above extensions are used in CLI PHP scripts to achieve Inter-Process Communications (IPC). In the absence of true multi-threading, it is common that a script will fork itself into several worker processes to emulate a true multithreaded program as close as possible. Typical multithreading issues like race conditions are combated with semaphores, while shared memory and message queues are used to exchange information. Since the different threads do not run in the same process, directly exchanging variables is not possible. While there are other options to achieve IPC (unix pipes, sockets, filesystem, database), shared memory and message queues are potentially less complex to implement.

My recommendation would be to keep these extensions bundled into one IPC option. The extensions are perfectly usable on an individual basis, but will often be used in combination with each other. Personally, I can see why you suggested to split the sysv_* and shmop extensions. The shmop extension is not prefixed with sysv after all. But as far as I know, they both wrap the same low level libraries.

Last edited 7 years ago by bas@… (previous) (diff)

comment:4 Changed 7 years ago by ryandesign (Ryan Schmidt)

Cc: mantas@… added

Has duplicate #41235.

comment:5 Changed 7 years ago by mantas@…

Hi, yes, this is the same issue. Would you guys be able to include the IPC versions of php53, php54 and php55? Thanks. We need to switch between them, and the only way to achieve this is to manually change the Portfiles, which is not ideal, as the whole team would have to follow the instructions.

comment:6 Changed 7 years ago by unwiredbrain@…

Cc: unwiredbrain@… added

Cc Me!

comment:7 Changed 7 years ago by unwiredbrain@…

Any news on this?

comment:8 in reply to:  description Changed 6 years ago by mantas@…

Something was changed in the portfile (and possibly other places) of php53 (and maybe php5), which does not compile IPC support, even if I manually add --enable-shmop --enable-sysvsem --enable-sysvshm --enable-sysvmsg ir still does not compile IPC. 2 weeks ago this worked fine, from yesterday we can't get it to work anymore. We need a permanent fix for this!

comment:9 Changed 6 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: assignedclosed

Sorry for the delay. I've added the php53-ipc, php54-ipc and php55-ipc subports in r114383.

comment:10 Changed 6 years ago by mantas@…

Tested, works great! Thanks for the fix.

comment:11 Changed 6 years ago by bas@…

Thanks for the implementation!

Note: See TracTickets for help on using tickets.