You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes wrapping a code with fork() may produce a compiler error that asks to "simplify" code inside the forked function.
It would be nice to have an annotation like @kphp-forkable that can be used above classes or functions to make sure the compiler will always check them for being forkable even if there are no actual fork() invocations for these functions.
This may help in following scenario:
I create simple merge request that introduces new repository (which sends RPC requests under the hood). For this task I don't need some forks because this task is pretty simple. That's why I don't care about forks here.
Then I create another merge request with more complex logic, and I need to fork() some method from the repository created in the previous merge request. In this case I need to refactor the repository to make sure code is "simple" enough to be forked.
If I had an annotation then unnecessary refactoring in the 2nd merge request may be avoided. Because when I was developing the repository in the 1st merge requests I could predict in advance that the repository may be forked by somebody in the future because it's an abstraction over network operation (RPC request).
The text was updated successfully, but these errors were encountered:
Sometimes wrapping a code with
fork()
may produce a compiler error that asks to "simplify" code inside the forked function.It would be nice to have an annotation like
@kphp-forkable
that can be used above classes or functions to make sure the compiler will always check them for being forkable even if there are no actualfork()
invocations for these functions.This may help in following scenario:
fork()
some method from the repository created in the previous merge request. In this case I need to refactor the repository to make sure code is "simple" enough to be forked.If I had an annotation then unnecessary refactoring in the 2nd merge request may be avoided. Because when I was developing the repository in the 1st merge requests I could predict in advance that the repository may be forked by somebody in the future because it's an abstraction over network operation (RPC request).
The text was updated successfully, but these errors were encountered: