On Mon, 2014-11-17 at 20:08 +0100, Manfred Spraul wrote:
> Hi Steven,
>
> On 11/16/2014 08:40 PM, Steven Stewart-Gallus wrote:
> > Finally, please don't ignore the rest of my message. Even if my patch
> > isn't that good there are lots of ways to compromise and improve it
> > such as adding
Hi Steven,
On 11/16/2014 08:40 PM, Steven Stewart-Gallus wrote:
Finally, please don't ignore the rest of my message. Even if my patch
isn't that good there are lots of ways to compromise and improve it
such as adding tests, annotations and making it clearer.
I think you were already given
Hi Steven,
On 11/16/2014 08:40 PM, Steven Stewart-Gallus wrote:
Finally, please don't ignore the rest of my message. Even if my patch
isn't that good there are lots of ways to compromise and improve it
such as adding tests, annotations and making it clearer.
I think you were already given
On Mon, 2014-11-17 at 20:08 +0100, Manfred Spraul wrote:
Hi Steven,
On 11/16/2014 08:40 PM, Steven Stewart-Gallus wrote:
Finally, please don't ignore the rest of my message. Even if my patch
isn't that good there are lots of ways to compromise and improve it
such as adding tests,
Hello,
My intent with my patch was to make things easier to understand
because it reduces the size of critical sections to more
understandable bite sized chunks. My patch would make the purposes of
the critical sections more obvious and understandable. In making this
patch I may have made a few
Hello,
My intent with my patch was to make things easier to understand
because it reduces the size of critical sections to more
understandable bite sized chunks. My patch would make the purposes of
the critical sections more obvious and understandable. In making this
patch I may have made a few
On Sat, 2014-11-15 at 04:44 +, Steven Stewart-Gallus wrote:
> > What's the benefit here? Seems very risky at very little gain.
> >
> > The juice ain't worth the squeeze. NAK
>
> Hello,
>
> It is fair to argue that these changes are too tiny to be very
> meaningful for performance but the
On Sat, 2014-11-15 at 04:44 +, Steven Stewart-Gallus wrote:
What's the benefit here? Seems very risky at very little gain.
The juice ain't worth the squeeze. NAK
Hello,
It is fair to argue that these changes are too tiny to be very
meaningful for performance but the other goal of
> What's the benefit here? Seems very risky at very little gain.
>
> The juice ain't worth the squeeze. NAK
Hello,
It is fair to argue that these changes are too tiny to be very
meaningful for performance but the other goal of this patch was also
to make the code look cleaner and easier for me
Hello, thank you for the criticism.
> It's probably better to do this as three or four separate patches.
Really? Alright if you insist I'll do the next version as multiple
patches.
> Well yes, that's what EMFILE means but "too_many_open_files" doesn't
> make sense in this context!
Fair enough,
Hello, thank you for the criticism.
It's probably better to do this as three or four separate patches.
Really? Alright if you insist I'll do the next version as multiple
patches.
Well yes, that's what EMFILE means but too_many_open_files doesn't
make sense in this context!
Fair enough, I'll
What's the benefit here? Seems very risky at very little gain.
The juice ain't worth the squeeze. NAK
Hello,
It is fair to argue that these changes are too tiny to be very
meaningful for performance but the other goal of this patch was also
to make the code look cleaner and easier for me and
On Fri, 2014-11-07 at 05:40 +, Steven Stewart-Gallus wrote:
> This shouldn't be too controversial. I simply looked for where there
> was a tiny bit of waste in the message queue code.
What's the benefit here? Seems very risky at very little gain.
The juice ain't worth the squeeze. NAK
--
To
On Fri, 2014-11-07 at 05:40 +, Steven Stewart-Gallus wrote:
This shouldn't be too controversial. I simply looked for where there
was a tiny bit of waste in the message queue code.
What's the benefit here? Seems very risky at very little gain.
The juice ain't worth the squeeze. NAK
--
To
On Fri, 07 Nov 2014 05:40:37 + (GMT) Steven Stewart-Gallus
wrote:
> This shouldn't be too controversial. I simply looked for where there
> was a tiny bit of waste in the message queue code.
>
It's probably better to do this as three or four separate patches.
> --- a/ipc/mqueue.c
> +++
On Fri, 07 Nov 2014 05:40:37 + (GMT) Steven Stewart-Gallus
sstewartgallu...@mylangara.bc.ca wrote:
This shouldn't be too controversial. I simply looked for where there
was a tiny bit of waste in the message queue code.
It's probably better to do this as three or four separate patches.
This shouldn't be too controversial. I simply looked for where there
was a tiny bit of waste in the message queue code.
Signed-off-by: Steven Stewart-Gallus
---
diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index 4fcf39a..aa3f903 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -278,16 +278,29 @@
This shouldn't be too controversial. I simply looked for where there
was a tiny bit of waste in the message queue code.
Signed-off-by: Steven Stewart-Gallus sstewartgallu...@mylangara.bc.ca
---
diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index 4fcf39a..aa3f903 100644
--- a/ipc/mqueue.c
+++
18 matches
Mail list logo
