On Sat, Jun 8, 2013 at 7:07 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
> On Sat, Jun 8, 2013 at 6:56 PM, Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
>> On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
>>> but how many people on this
>>> list understand git design and limits _and_ ruby's good enough to spot
>>> the bugs?
>>
>> Now you are changing the subject. Does that mean that you accept that
>> 'fork' wouldn't be a problem when writing Ruby scripts?
>
> There are a lot of static variables in builtin/ (and outside too),
> which make it non-entrant, or at least not safe.
So?
> fork provides a process space isolation, some depend on that.
Process space isolation from what?
> And there are die() everywhere. Good luck controlling them.
Done.
--- a/ruby/git.c
+++ b/ruby/git.c
@@ -1,6 +1,7 @@
#include <builtin.h>
#include <cache.h>
#include <fcntl.h>
+#include <ucontext.h>
#undef NORETURN
#undef PATH_SEP
@@ -8,6 +9,8 @@
#include <ruby.h>
static VALUE shellwords;
+static ucontext_t main_context;
+static int status;
struct cmd_struct {
const char *cmd;
@@ -73,7 +76,14 @@ static VALUE git_rb_backticks(int o_argc, VALUE
*o_argv, VALUE ctx)
if (cmd->option & RUN_SETUP)
prefix = setup_git_directory();
- i = cmd->fn(argc, argv, prefix);
+ getcontext(&main_context);
+ if (status == 0) {
+ status += 1;
+ i = cmd->fn(argc, argv, prefix);
+ } else {
+ i = 1;
+ }
+ status = 0;
rb_last_status_set(i, getpid());
fflush(stdout);
@@ -87,9 +97,19 @@ static VALUE git_rb_backticks(int o_argc, VALUE
*o_argv, VALUE ctx)
return rb_str_new(buf, i);
}
+static void bye(void)
+{
+ if (status != 1)
+ return;
+ status += 1;
+ setcontext(&main_context);
+}
+
void Init_git(void)
{
rb_require("shellwords");
shellwords = rb_define_module("Shellwords");
rb_define_global_function("`", git_rb_backticks, -1);
+
+ atexit(bye);
}
>> As for the people that know Git and Ruby; they can learn. Didn't you
>> just said that you didn't see any problem with the community learning
>> a new language?
>
> I said nothing about the community being ready _now_, did I?
If they can learn Ruby five years from now, then can learn it now.
> When you have the support for Ruby in Git, sure go ahead.
You are going in circles.
>>> If a bug is found and requires major restructuring in
>>> libgit.a, how are you sure it's worth the effort and does not
>>> destablize the rest of git?
>>
>> There is no need to destabilize anything. I just showed you 100 lines
>> of code that are able to run git commands without forks, and without
>> changing anything in libgit.a.
>
> And how do you deal with, for example die(), or thread safety?
See above for die(), and I don't see many perl or shell scripts with
multiple threads, why should the Ruby scripts have more than one
thread?
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html