| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
| |
actually a server process.
This should be implemented for other OSes, too, but OS X seems to lack a procfs and it's not clear how to discover anything about a process based on its PID and of course, Windows is a wholly different cup of tea.
More work for #930.
--
MOS_MIGRATED_REVID=121262673
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Made the control flow much simpler and more understandable
- Added some documentation about the interplay of the client and the server
- Abstracted out POSIX mechanisms from blaze.cc so that they can be implemented properly on Windows
- Added assertions that the methods on BlazeServer are called when they should be
Polish for #930.
--
MOS_MIGRATED_REVID=121256601
|
|
|
|
|
|
|
|
|
| |
This is so that only one server instance is started up if two clients are started in a workspace that doesn't have a running server yet.
More work towards #930. This may break Windows in case flock() doesn't work there as expected. In anticipation of this, locking is moved to blaze_util_platform.h / blaze_util.cc .
--
MOS_MIGRATED_REVID=121013078
|
|
|
|
|
|
|
|
|
| |
This is still fallout from a bad merge I did yesterday.
More progress towards #930.
--
MOS_MIGRATED_REVID=121006319
|
|
|
|
|
|
|
| |
way that actually works.
--
MOS_MIGRATED_REVID=120997894
|
|
|
|
|
|
|
|
|
| |
This change makes it possible to build Bazel with itself in server mode.
Progress towards #930 . Does not completely fix it because there are still a bunch of issues that need to be taken care of, but it's usable.
--
MOS_MIGRATED_REVID=120994369
|
|
|
|
|
|
|
|
|
|
|
|
| |
The correct spelling of it, is, of course, "common".
While at this, this also fix a mistaken usage of "from" instead of
"form" in ConvertPath() documentation.
--
Change-Id: If93984b57da0c98b6dfe4ca70fd4158bd9e1a861
Reviewed-on: https://bazel-review.googlesource.com/#/c/3500
MOS_MIGRATED_REVID=120921796
|
|
|
|
|
|
|
|
|
| |
AF_UNIX doesn't work on Windows, so it doesn't make much sense to try.
Progress towards #930.
--
MOS_MIGRATED_REVID=120912873
|
|
|
|
|
|
|
|
|
| |
This is necessary because msys2 signals don't work on native Win32 processes, for example, java.exe .
Forcefully terminating the process still doesn't work because it uses signals. It's a-coming.
--
MOS_MIGRATED_REVID=120903711
|
|
|
|
|
|
|
| |
This is necessary because a SIGINT can strike at any time, including when the main thread holds the mutex.
--
MOS_MIGRATED_REVID=120816015
|
|
|
|
|
|
|
|
|
| |
new ones.
Add server.pid.txt that contains the same information in text form. ExecuteDaemon() on Windows will simply not write server.pid .
--
MOS_MIGRATED_REVID=120802055
|
|
|
|
|
|
|
|
|
|
| |
There is no |lock_file| in GlobalVariables structure. Actually,
it was referring to |lockfile| variable.
--
Change-Id: Ic27bd4fad79c2e8b98ae8fa701d0b81fbdd98aa2
Reviewed-on: https://bazel-review.googlesource.com/#/c/3360/
MOS_MIGRATED_REVID=120792865
|
|
|
|
|
|
|
| |
This is so that they can be implemented properly for Windows. For now, though, they are left in blaze_util.cc since the Windows implementations aren't there yet.
--
MOS_MIGRATED_REVID=120709884
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=120702105
|
|
|
|
|
|
|
| |
server down due to differing startup options.
--
MOS_MIGRATED_REVID=120697380
|
|
|
|
|
|
|
| |
This is just a minor fix because when this call happens, the other thread is not running yet, but better be safe than sorry.
--
MOS_MIGRATED_REVID=120695754
|
|
|
|
|
|
|
| |
This is because OsUtils.getpid() cannot work under msys2 since java.exe is not an msys2 binary. We might make it work by including JNI code, but the current plan is to go without JNI on Windows.
--
MOS_MIGRATED_REVID=120694746
|
|
|
|
|
|
|
| |
This is necessary because on Windows/msys2, the Java gRPC server listens only on IPv6 but the C++ client only tries to connect over IPv4, resulting in breakage.
--
MOS_MIGRATED_REVID=120689437
|
|
|
|
|
|
|
| |
I wonder why it was implemented like this in the first place. Unsurprisingly, it doesn't work on Windows.
--
MOS_MIGRATED_REVID=120682316
|
|
|
|
|
|
|
|
|
| |
- Actually make it work again (commit 00cfb7df61b1f3d9fac8ee29d92b315cbfe6d28f broke it, maybe I shouldn't send out changes in a hurry next time)
- Rename --grpc_port to --command_port (it's a bit better name)
- Do not send a kill signal to the server that can't be connected if we only connect to it to verify its presence
--
MOS_MIGRATED_REVID=120418784
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=120315714
|
|
|
|
|
|
|
| |
Fixes #1156.
--
MOS_MIGRATED_REVID=120312138
|
|
|
|
|
|
|
| |
when in gRPC mode.
--
MOS_MIGRATED_REVID=120233121
|
|
|
|
|
|
|
|
|
|
|
| |
Drive-by fix: eliminate the GRPC messages from the console by passing a null logging function.
This also prepares us for the time when multiple commands will be running, because then we'll need to tell which command exactly we want to interrupt.
Work towards #930.
--
MOS_MIGRATED_REVID=120203008
|
|
|
|
|
|
|
|
|
| |
C symbols.
Fixed #1155.
--
MOS_MIGRATED_REVID=120107746
|
|
|
|
|
|
|
|
| |
This hashes together a user name and an workspace directory, and
uses less bits from MD5 hash to make the path much shorter.
--
MOS_MIGRATED_REVID=119952145
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This still has a number of issues, including, but not limited to:
- When switching between gRPC and AF_UNIX mode, you need to do a manual shutdown
- The console is spammed with "connection refused" messages on server startup
- When in gRPC mode, server also starts up an AF_UNIX server even though it's not necessary and concurrent requests probably make Bazel crash and burn
- I have no idea how concurrent gRPC requests are handled and now many threads gRPC creates
- Not tested except under Linux
- The request/response cookies are written in an odd format (negative bytes are not handled correctly). This is only a cosmetic issue, since the data content of the string is the same either way.
Can be tested with the --grpc_port=0 (or a valid port number) startup option.
--
MOS_MIGRATED_REVID=119948959
|
|
|
|
|
|
|
| |
communication alongside AF_UNIX.
--
MOS_MIGRATED_REVID=119943481
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that the presence of server/grpc_port does not guarantee that the server actually listens to it and we can't guarantee it, either, because it can always be kill -9'd.
I haven't decided yet how the transition between AF_UNIX and gRPC will work. For now, I'm happy that we can start up a Java server.
The way to get the kernel-chosen port is truly awful, but it is apparently impossible to do so in a different way:
https://github.com/grpc/grpc-java/issues/72
--
MOS_MIGRATED_REVID=119828354
|
|
|
|
|
|
|
| |
The code doesn't do anything yet and it's unused code for now. This change only serves to add all the necessary dependencies to BUILD files that gRPC needs.
--
MOS_MIGRATED_REVID=119628697
|
|
|
|
|
|
|
| |
value 90. When --experimental_oom_more_eagerly is enabled, if after two full GCs the old gen is still >=--experimental_oom_more_eagerly_threshold% full, exit the JVM.
--
MOS_MIGRATED_REVID=117943361
|
|
|
|
|
|
|
|
|
| |
Windows.
Progress towards #930.
--
MOS_MIGRATED_REVID=117799006
|
|
|
|
|
|
|
| |
OutOfMemoryError and have the JVM send Bazel a SIGUSR2 when it detects an OOM. This should help in certain pathological cases when Bazel GC thrashes for some time after an OOM has been detected.
--
MOS_MIGRATED_REVID=116819359
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This functions was introduced by commit bf98f39d5d69: "Add the ability
to customize the bazel client's...", but at that time it didn't update
EnsureCorrectRunningVersion() function, that uses unlink() function, to
use DeleteFile() as well.
So this patch updates EnsureCorrectRunningVersion() to make use of it
now.
While there is nothing wrong with the current name, it is not very much
correct from the documentation point. If the path is a symlink, unlink()
will just the symbolic link and the file won't be removed (affected at all).
Otherwise, if it is just a normal file, it will just decrement the link
count of the file and when that count reaches zero (0) then the file
will longer be accessible.
So while at it we renamed the function to UnlinkPath(), but could just
stay as DeleteFile() if we wanted.
In this process we also improved the documentation for this function to
be a little more clear and removed moved it from the source file, since
the header file already has it.
For further reference, adhere to the documentation in
http://pubs.opengroup.org/onlinepubs/009695399/functions/unlink.html.
--
Change-Id: I0fc569f3324322cbc67a8fb540836c127f5c3399
Reviewed-on: https://bazel-review.googlesource.com/#/c/3061/
MOS_MIGRATED_REVID=116769254
|
|
|
|
|
|
|
| |
Bazel exit more eagerly due to an OOM will be guarded by this flag.
--
MOS_MIGRATED_REVID=116567102
|
|
|
|
|
|
|
|
|
|
| |
Win32 have no good API for that (basically we need to resort to ioctl
call). Shelling out to mklink.
Needed for #276.
--
MOS_MIGRATED_REVID=115040968
|
|
|
|
|
|
|
|
|
| |
for a long time.
RELNOTES: The --skyframe flag is no longer available for the build command.
--
MOS_MIGRATED_REVID=113947409
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=113556731
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=113366155
|
|
|
|
|
|
|
|
|
|
|
|
| |
The consumers of Connect() function are just interested in knowning if
it has connected or not ("Did we connect?"). Leave the check for zero as
implementation detail of this function, making the callsites not having
to repeat the condition themselves.
--
Change-Id: Idc327c681c5defbb27039cd170f32d5ebd0e0a32
Reviewed-on: https://bazel-review.googlesource.com/#/c/2750/
MOS_MIGRATED_REVID=113040325
|
|
|
|
|
|
|
|
|
| |
ParseOptions() function does not return any value (its type is void).
--
Change-Id: I7e3b818169a304cc2ad6c8d1580ce010b7d79d12
Reviewed-on: https://bazel-review.googlesource.com/#/c/2740/
MOS_MIGRATED_REVID=112762600
|
|
|
|
|
|
|
|
|
|
|
| |
It is counter-intuitive to read ConnectToServer(false). By having
/*start=*/ in front of the boolean parameter the intention gets clear
(i.e., if it should or not start the Java server).
--
Change-Id: I74847deb6ec7daba62facd7a746d418943448182
Reviewed-on: https://bazel-review.googlesource.com/#/c/2680
MOS_MIGRATED_REVID=112466249
|
|
|
|
|
|
|
| |
bazel server exits abruptly.
--
MOS_MIGRATED_REVID=111641619
|
|
|
|
|
|
|
| |
shim is done, and Blaze now always preserves spaces in host_jvm_args.
--
MOS_MIGRATED_REVID=111523524
|
|
|
|
|
|
|
|
|
| |
$OUTPUT_BASE/execroot/<workspace name> instead of $OUTPUT_BASE/<workspace name>.
This makes it possible to run Bazel in directories whose name clashes with one of the pre-existing files in the output base. Note that this option is turned off by default for now.
--
MOS_MIGRATED_REVID=109791053
|
|
|
|
|
|
|
| |
now deprecated. Pass each JVM option behind its own --host_jvm_args flag.
--
MOS_MIGRATED_REVID=108085362
|
|
|
|
|
|
|
|
|
| |
through to the JVM instead of (almost certainly incorrectly) splitting the options along spaces.
This allows us to pass non-quote-delimited strings to the JVM, which is necessary for things like -XX:OnOutOfMemoryError="kill -3 %p" (normally bash strips those quotes, but they're not stripped when passed via --host_jvm_args).
--
MOS_MIGRATED_REVID=107820087
|
|
|
|
|
|
|
| |
server death" implementation. Boost grace period on SIGKILL to 10s.
--
MOS_MIGRATED_REVID=106080991
|
|
|
|
|
|
|
|
|
|
|
| |
running server (because startup flags changed, different Blaze version, etc.). Currently, we do a SIGTERM then fallback to a SIGKILL. Our logic to check if the server was still up after the fallback was backwards, so in some cases we would connect to the old server even though we just sent it a SIGKILL. Not really ideal.
Note that this only occurred if the SIGTERM failed to kill the Blaze process within 10s, so this failure mode happened rarely.
Also: Check for the expected errno from the kill(), and exit with an "internal error" exit code instead of "1" if we are unable to kill the old server.
--
MOS_MIGRATED_REVID=105999230
|
|
|
|
|
|
|
| |
A previous commit caused install_base_key to be a large .zip file instead of 32 alphanumeric characters. Thus, when Bazel tried to extract itself, it tried to create a directory of the name "$INSTALL_BASE/<40M path segment>/<long path>", and it allocated said 40M each time it walked up a path segment trying to create parent directories.
--
MOS_MIGRATED_REVID=105600489
|