Skip to content

Dereferencing process-handles no longer waits on those processes - #130

Closed
Jille wants to merge 1 commit into
php:masterfrom
Jille:proc_close_lingering
Closed

Jille wants to merge 1 commit into
php:masterfrom
Jille:proc_close_lingering

Conversation

@Jille

@Jille Jille commented Jul 12, 2012

Copy link
Copy Markdown
Contributor
When handles created by proc_open() and popen() got destroyed they called waitpid() and waited for the process to exit. Now they only wait if they are explicitly closed with proc_close() or pclose().

Implements FR #46487

I will also send this over internals to be discussed.

@lstrojny

lstrojny commented Jan 6, 2013

Copy link
Copy Markdown
Contributor

@Jille patch looks good. Can you add a test for your patch?

@lstrojny

Copy link
Copy Markdown
Contributor

Could you rebase and squash?

@Jille

Jille commented Jan 15, 2013

Copy link
Copy Markdown
Contributor Author

I've committed f2bad2c to Jille/php-src:proc_close_lingering_squashed.

@lstrojny

Copy link
Copy Markdown
Contributor

Please force push to this PR as well.

@Jille

Jille commented Jan 15, 2013

Copy link
Copy Markdown
Contributor Author

Done.

@lstrojny

Copy link
Copy Markdown
Contributor

Hm, the test is gone?

@Jille

Jille commented Jan 15, 2013

Copy link
Copy Markdown
Contributor Author

I'm sorry. Fixed.

@php-pulls

Copy link
Copy Markdown

Comment on behalf of lstrojny at php.net:

Merged into 5.5 and master. 5.5 and not 5.4 because it comes with an ABI break.

@php-pulls php-pulls closed this Jan 15, 2013
heyJordanParker added a commit to heyJordanParker/php-sharp that referenced this pull request Oct 13, 2026
test: every .sharp issue speaks PHP#, and .php twins stay only on shared code
heyJordanParker added a commit to heyJordanParker/php-sharp that referenced this pull request Oct 13, 2026
Problem:
Master gained php#153, php#154 and php#130. php#153 makes the same `None` fix to
`check_changed_collection` that the previous merge made, so it merges cleanly.

php#154 gives `get_parameter_type` the invocation target, so a plain PHP caller reads a PHP
declaration only of a method a PHP# file declares. This branch's call in
`analyze_invocation`, which fixes a PHP# method value's type arguments from its parameter's
function type, still passed six arguments.

php#130 fails any test whose `.sharp` issue names a word only PHP has, `mixed` among them. This
branch prints the type a generic member erases to as PHP declares it, so an unbounded type
parameter's erased type read "PHP's `mixed`", and six erased-signature tests failed the
check. `crates/analyzer/src/expression/access/mod.rs` gained an import on both sides.

Solution:
- `analyze_invocation` passes `&invocation.target` to `get_parameter_type`, as php#154's other
  callers do.
- `display_erased` prints an erased `mixed` as PHP# writes it, `Any?`, through
  `display_sharp_type`. Only `array`, `Closure` and `callable` stay PHP's, since PHP# has
  no name for them. The six tests pin "must take at least `Any?`" and "erases to `Any?`".
- `access/mod.rs` keeps both imports.

crates/analyzer/
├── src/expression/access/mod.rs                     <- conflict: both imports
├── src/invocation/analyzer.rs                       <- php#154's invocation target
├── src/statement/class_like/method_signature.rs     <- display_erased names `Any?`
└── tests/sharp.rs                                   <- six erased-signature texts
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants