From: Johannes Schindelin Date: Fri, 29 Feb 2008 01:17:39 GMT Subject: Re: [PATCH 22/40] Windows: Implement asynchronous functions as threads. Message-ID: In-Reply-To: <200802282201.06802.johannes.sixt@telecom.at> Hi, On Thu, 28 Feb 2008, Johannes Sixt wrote: > On Thursday 28 February 2008 16:28, Johannes Schindelin wrote: > > > On Wed, 27 Feb 2008, Johannes Sixt wrote: > > > In upload-pack we must explicitly close the output channel of > > > rev-list. (On Unix, the channel is closed automatically because > > > process that runs rev-list terminates.) > > > > When I read this patch, my impression was that it litters the source > > code with #ifdef's. IMO this makes the code less readable, and as a > > consequence easer to fsck up. > > > > Unfortunately, I have no idea how to help that, other than > > implementing compat/thread.[ch], abstracting the thread functions, and > > introducing a NO_FORK Makefile variable and preprocessor constant. > > > > Hmpf. > > The number of #ifdef/#endif is already at a minimum unless you are > willing to have entire functions in separate #ifdef/#else/#endif > branches. Whether to have compat/thread.[ch] or not is just a question > of whether you want to have asynchronous functions in threads also on > Unix or not. Well, my idea was that Git's code looks as good as it does now not only because the functions are well written, but because the conditionally-compiled code is not classified by _platform_ but by _reason_. For example, we do not write that on FreeBSD, we do this and that, but we define for FreeBSD that there is no strlcpy(), and if NO_STRLCPY is defined, we implement it. Likewise, I would prefer to have it in the code here _not_ that we do this and that on MinGW32, but that in the absence of a usable fork(), we require certain functions (declared in compat/thread.h, for example), and use them. But I know this is a lot of work, so I hoped for a better solution, that still excites my "elegance neuron". Ciao, Dscho