[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #33138] .PARLLELSYNC enhancement with patch
From: |
Eli Zaretskii |
Subject: |
Re: [bug #33138] .PARLLELSYNC enhancement with patch |
Date: |
Wed, 24 Apr 2013 21:30:52 +0300 |
> Date: Wed, 24 Apr 2013 10:34:20 -0700
> From: David Boyce <address@hidden>
> Cc: Frank Heckenbach <address@hidden>,
> "address@hidden" <address@hidden>
>
> On Wed, Apr 24, 2013 at 10:26 AM, Tim Murphy <address@hidden> wrote:
>
> > I would suggest pretending that one has semaphores first with some nice
> > little abstraction and then implementing them in the best way the platform
> > has to offer.
>
> How about we introduce functions called acquire_semaphore() and
> release_semaphore()? Oh, wait, we did.
Sorry, but this is not funny. There are, indeed, such functions, but
that's about all there is about modularity in the implementation. The
rest is code scattered all over the place, that _knows_ all too well
that it is dealing with file descriptors, not with some abstract
semaphores or mutexes. Here's a good example:
if (output_sync)
{
static int combined_output;
/* If output_sync is turned on, find a resource to
synchronize on. This block is traversed only once. */
if (sync_handle == -1)
{
if (STREAM_OK (stdout))
{
struct stat stbuf_o, stbuf_e;
sync_handle = fileno (stdout);
combined_output =
fstat (fileno (stdout), &stbuf_o) == 0 &&
fstat (fileno (stderr), &stbuf_e) == 0 &&
stbuf_o.st_dev == stbuf_e.st_dev &&
stbuf_o.st_ino == stbuf_e.st_ino;
}
else if (STREAM_OK (stderr))
sync_handle = fileno (stderr);
else
{
perror_with_name ("output-sync suppressed: ", "stderr");
output_sync = 0;
}
}
There are 2 separate things intermixed here: determination of
combined_output and determination of the resource to use as a mutex.
They are mixed because they both deal with file descriptors, and it
was just convenient, by sheer luck (or maybe because of something
else) to save a few if's and do them together.
But this is exactly where abstractions "leak" and break.
It will come as small surprise, I'm sure, that the corresponding code
in the Windows branch looks different, because there the two decisions
are uncoupled.
> I have the impression Eli has the Windows port in hand
Almost, yes. I needed to invest some time into researching how to do
is_same_file, STREAM_OK, CLOSE_ON_EXEC, etc. But I'm getting there.
> he's just skeptical about a few details.
Not anymore, thanks.
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, (continued)
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Frank Heckenbach, 2013/04/24
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Eli Zaretskii, 2013/04/24
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Frank Heckenbach, 2013/04/23
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Paul Smith, 2013/04/21
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, David Boyce, 2013/04/18
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Eli Zaretskii, 2013/04/18
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Eli Zaretskii, 2013/04/24
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Frank Heckenbach, 2013/04/24
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Tim Murphy, 2013/04/24
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, David Boyce, 2013/04/24
- Re: [bug #33138] .PARLLELSYNC enhancement with patch,
Eli Zaretskii <=
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Eli Zaretskii, 2013/04/24
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Eli Zaretskii, 2013/04/26