From: tsgates <tsgatesv@gmail.com>
To: git@vger.kernel.org
Subject: Dumb idea on git library for script languages
Date: Mon, 28 Apr 2008 16:03:36 +0900 [thread overview]
Message-ID: <1209366216.17090.4.camel@prosumer> (raw)
Please comment on my naive idea.
When I try to use git in python, there are no fancy ways not to fork any
processes. (except not active git library) I know it is design policy
of git, one job for one process.
Anyhow, I need to call git in python and perl, so I try to think.
I assumed that
1. all cmd_*() is designed in a process basis,
so it is ok to free all memories which invoked after calling cmd_*()
2. result of cmd_*() is output only
so parse it in order to use in script language
right before call cmd_*() -> redirect stdout to anything
3. 'die()' can be escaped by using "setjmp/longjmp"
4. actually I need only cmd_*() or little low level functions from
script
here is snippets of naive pseudo codes
------------------------------------------------------------
# will be called from the python/perl code
------------------------------------------------------------
lib_git_do() {
if ( setjmp( exterend here ) ) {
start_trace()
cmd_do()
stop_trace()
} else {
# called from die (from longjmp)
return error occured
}
return parse_do();
}
------------------------------------------------------------
start_trace() {
init_mem()
start_malloc_trace()
start_stdout_trace()
}
stop_trace() {
stop_stdout_trace()
stop_malloc_trace()
clean_mem()
}
start_malloc_trace() {
hook __malloc_hook
hook __realloc_hook
hook __free_hook
}
malloc_hook( size ) {
void * rtn = malloc( size )
if ( rtn ) {
add_to_mem_record( thread_id, rtn )
}
}
free_hook( ptr ) {
if ( free( ptr ) ) {
del_mem_record( thread_id, ptr )
}
}
clean_mem() {
for_each ( mem_records )
free( ptr )
}
------------------------------------------------------------
pros
0. easy to implement
1. guarantee thread safety
2. no memory leak
3. not depend on git source
4. able to take advantage of script codes, no forking overhead
cons
0. not fancy
1. need dumb parsing
2. just temporary solution
but, I want to use it in review board or track like system, right now.
If there are any other good suggestions or recommendations on it, please
recommend it.
Best regards
next reply other threads:[~2008-04-28 7:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-28 7:03 tsgates [this message]
2008-04-28 7:31 ` Dumb idea on git library for script languages Jakub Narebski
2008-04-28 10:28 ` Johannes Schindelin
2008-04-29 4:06 ` Eric Hanchrow
2008-04-29 4:25 ` Govind Salinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1209366216.17090.4.camel@prosumer \
--to=tsgatesv@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).