-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fixed SYS___pthread_chdir value for FreeBSD when making call to syscall #109
Conversation
static { | ||
if (OS == OperatingSystem.MAC) { | ||
O_NONBLOCK = 0x0004; // MacOS X, Freebsd | ||
O_NONBLOCK = 0x0004; // MacOS X, Freebsd |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the pull request, but please remove unrelated whitespace changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whitespace has been removed, sorry about that.
@@ -81,8 +90,7 @@ public static native int posix_spawnp(IntByReference restrict_pid, String restri | |||
// We can't use JNA direct mapping for syscall(), since it takes varargs. | |||
public interface SyscallLibrary extends Library | |||
{ | |||
public static final int SYS___pthread_chdir = 348; | |||
|
|||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we don't put the chdir
constant back here, should this line be removed?
@@ -27,14 +27,23 @@ | |||
@SuppressWarnings("WeakerAccess") | |||
public class LibC | |||
{ | |||
|
|||
public static int SYS___pthread_chdir = 348; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't seem like this should be mutable. This is clearly intended to be a constant.
Rather than initializing this here and changing it in the static
block, which requires this to be mutable, leave it uninitialized here and update the static
block to set the "right" value:
public static final int SYS___pthread_chdir;
static {
// O_NONBLOCK initialization as now
SYS___pthread_chdir = System.getProperty("os.name").toLowerCase().contains("freebsd") ? 12 : 348;
// Register Native
}
If this constant is going to move to LibC
, should it be further down, with the others (like O_NONBLOCK
)? Alternatively, perhaps the constant should just stay where it was, paired with a new static
block inside SyscallLibrary
to initialize it?
I just wanted to make the point that Setting It is possible that FreeBSD developers might some day add support for But, in the meantime, I think the whole approach here is wrong – since NuProcesses' macOS process startup code is based on A better approach could be something like this:
|
Thanks for the detailed feedback, @skissane! I'll readily admit, I lack the depth of knowledge you have around FreeBSD and how some of these internals work there. Looking purely at end behavior, though, trying to use the per-process work directory to control working directories for processes we spawn, and can actively be spawning on multiple threads concurrently, seems like an obvious no-no. (I no longer work on Bitbucket Server, but thinking about this in terms of Bitbucket Server's usage of the library it'd be pretty disastrous to, for example, have 2 threads that are trying to operate on different repositories end up racily changing the process-wide working directory and one thread's update stomps the other, resulting in the forked Based on that potential issue, and reinforced given that I asked for a variety of rework on this pull request over 3 years ago and it hasn't been actioned, I think the right approach is to decline this change and consider other options separately. One thing I'll add to that, though, is that I don't a) use FreeBSD or b) have any sort of FreeBSD setup, so I personally am unlikely to make any inroads on a solution to this issue. |
Fix for FreeBSD LibC chdir syscal