[darcs-users] [patch127] Re: patches to Darcs.Commands.ShowFiles, and repository internals

[Thomas Hartman]

With regards to http://bugs.darcs.net/patch127

> (But it is problematic in other ways, since this does not seem to be
> available from neither pthread API nor GHC threading API...)

I am interested in solving this problem but I admit a couple things.

1) I am not sure it is really a problem
2) This is pretty unfamiliar terrain for me.

Is it really a problem? I suspect it is, but I can't currently prove
it. I would like to introduce darcs api functions that return lists of
files/changes et al, and call these api functions directly from
patch-tag/gitit. If two users simultaneously query some informatin
about a repo, and cwd changes while in the middle of such an api call,
we're in trouble right? If we're not in trouble, of course I should
not be fixing a non-problem.

FWIW I'm not even currently running patch-tag server compiled with
-threaded. Does that mean I'm safe(r) in the above scenario? Happstack
(I assume) uses forkIOs or some equivalent in its implementation for
handling requests.

Suggestions for determining whether this is a problem or not, are welcome.

2) Assuming the answer to 1 is, it's a problem: where to begin? Solve
it in pthreads, solve it in the GHC threading API, or solve it somehow
else? I have not used the pthreads api from haskell (nor anywhere
else), can someone point me to a tutorial or howto? I assume the GHC
threading API is basically Control.Concurrent... is this right?

Guidance welcome here as well.


2010/1/13 Petr Ročkai <bugs at darcs.net>:
>
> Petr Ročkai <me at mornfall.net> added the comment:
>
> Hi,
>
> Thomas Hartman <bugs at darcs.net> writes:
>> What and where are the  CLONE_FS (...) flags ?
>>
>> ...darcs.net $ find -type d -name _darcs -prune -o -name *.hs -print |
>> xargs -i grep CLONE {} # (no output)
> sorry, I was referring to the Linux system call clone, which is used to
> create new threads. In Linux, threads can be created in such a way that
> each thread has its own working directory. This would likely solve your
> problem of darcs calling and relying on setCurrentDirectory, IIUIC?
>
> (But it is problematic in other ways, since this does not seem to be
> available from neither pthread API nor GHC threading API...)
>
> Yours,
>   Petr.
>
> __________________________________
> Darcs bug tracker <bugs at darcs.net>
> <http://bugs.darcs.net/patch127>
> __________________________________
> _______________________________________________
> darcs-users mailing list
> darcs-users at darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-users
>