We may fopen() an additional stdout and/or stderr handle, but do not fclose() it?

I am suspicious that D21794 may have broken something subtle with unix magic, since I'm seeing some hangs out of deployment scripts wrapping daemon management scripts. I think the issue is probably one of:

What options exist for inter-process communication?

Here's how I'm thinking about overengineering this:

How do modern servers written in C/C++ handle parallelizing requests?

Just for my own notes:

FWIW I've found by far the easiest way to work with microcontrollers is using micropython / circuitpython on any of these chips: ESP32, ATSAMD21/ATSAMD51 and RP2040. The esp32 is in many ways the easiest and most practical because it's extremely cheap and includes a wifi radio.

What are the practical limits of multi-system or multi-architecture binaries?

I generated D21794 with a native binary that has no dependency on system PHP (but does depend on system cURL).

1. PHP doesn't link cURL statically and doesn't appear (?) to provide any easy way to link it statically.
   1. • Possible solution: build static cURL.
      • Possible solution: link cURL dynamically.
      • Possible solution: replace cURL with mbedTLS + a first-party HTTP client, since we don't care about 99% of what cURL does. Or implement first-party TLS hahaha except I'm half-serious? If HTTP/HTTPS is going to happen from an embedded context on my coffee maker I need a healthy embeddable TLS + HTTP stack anyway.
   2. The STDERR and STDOUT constants are defined by the CLI SAPI, and not present in the embed SAPI.
      • Possible solution: define them in the C wrapper.
      • Possible solution: polyfill them at startup in PHP (I'm not entirely sure this is possible).
      • Possible solution: abstract around them and use php://stderr and php://stdout instead. See also T13556. This is likely desirable anyway.
   3. When arc tries to load PHP code, it needs to read data out of the executable binary in some set of conditions (e.g., "if we miss on disk").
      • Possible solution: hook zend_compile_file(), which seems to be the expected way to approach this. The flow in phar_compile_file() seems similar.
   4. To run unit tests, arc depends on the presence of a php binary on the system.
      • Possible solution: accept that you must also have PHP to run arc's tests (and that system PHP may differ from arc php).
      • Possible solution: also include the PHP CLI wrapper and invoke it when arc is executed as php, providing what is essentially a fallback toolset.
      • Possible solution: provide a "unit test helper" fallback toolset.
      • Possible solution: rewrite the 5 trivial cases where we need this (support/unit/*) in shell script (but: the reason to do these in PHP in the first place was so that they're portable to Windows).

Can we build a single binary with a bunch of data in it (e.g., a picture of a cat) without breaking anything?

Is the purpose of implementing introspection of libraries to allow for building native components that would get picked up and auto-loaded by arcanist?

I find this very intriguing.

Phabricator would benefit from having access certain services (full-text search, full-codebase search, repository graph storage) that very likely aren't practical to write in PHP

Is the purpose of implementing introspection of libraries to allow for building native components that would get picked up and auto-loaded by arcanist?

Browsing Diffusion (namely, loading a file while the published changeset is head, and trying to Skip past commit):

I couldn't immediately reproduce this; it's also probably a bit of a messy fix.

I'll plan to investigate further if possible. I believe in this case the repository was running in observed mode rather than hosted in case that might be a factor.

How can PHP be built statically? How hard is this?

Browsing Revision

I caught one cosmetic issue in D21711, but this works properly for me locally now. Thanks!

(After picking up D21697, the approach works properly in my environment where I originally ran into this, but there are a couple of rebase calls still present in ArcanistMercurialLandEngine that don't use the new API yet.)

Marking this as resolved by D21700. If there are further details or input we can re-open to further address.

I'm also surprised that rebase extension isn't enabled by default. I guess I have been turning it on in my default setup.

I like that idea. I'll take a look.

...perhaps we should consider a way to do this automatically or at least less-manually.