All of lore.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj38.park@gmail.com>
To: paulmck@kernel.org
Cc: perfbook@vger.kernel.org, SeongJae Park <sj38.park@gmail.com>
Subject: [PATCH 1/7] future/tm: Remove unnecessary spaces
Date: Sat,  2 Dec 2023 09:26:08 -0800	[thread overview]
Message-ID: <20231202172614.20239-2-sj38.park@gmail.com> (raw)
In-Reply-To: <20231202172614.20239-1-sj38.park@gmail.com>

A couple of sentences in future/tm.tex are having two spaces between two
words unnecessarily.  Remove one.

Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
 future/tm.tex | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/future/tm.tex b/future/tm.tex
index e6985099..1de900b8 100644
--- a/future/tm.tex
+++ b/future/tm.tex
@@ -126,7 +126,7 @@ Here are some options for handling of I/O within transactions:
 	However, special handling is required in cases where multiple
 	record-oriented output streams are merged onto a single file
 	from multiple processes, as might be done using the ``a+''
-	option to \co{fopen()} or the \co{O_APPEND}  flag to \co{open()}.
+	option to \co{fopen()} or the \co{O_APPEND} flag to \co{open()}.
 	In addition, as will be seen in the next section, common
 	networking operations cannot be handled via buffering.
 \item	Prohibit I/O within transactions, so that any attempt to execute
@@ -240,7 +240,7 @@ Here are some options available to TM:
 	back, with consequent degradation of performance and scalability.
 	This approach nevertheless might be valuable given long-running
 	transactions ending with an RPC\@.
-	This approach must still restrict  manual transaction-abort
+	This approach must still restrict manual transaction-abort
 	operations.
 \item	Identify special cases where the RPC response may be moved out
 	of the transaction, and then proceed using techniques similar
-- 
2.17.1


  reply	other threads:[~2023-12-02 17:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-02 17:26 [PATCH 0/7] future: Trivial fixups SeongJae Park
2023-12-02 17:26 ` SeongJae Park [this message]
2023-12-02 17:26 ` [PATCH 2/7] future/tm: Add introduction of TM-availabe options for locking SeongJae Park
2023-12-02 17:26 ` [PATCH 3/7] future/tm: Consistently add dash between reader and writer of reader-writer lock SeongJae Park
2023-12-02 17:26 ` [PATCH 4/7] future/htm: Remove unnecessary extra 'and' SeongJae Park
2023-12-02 17:26 ` [PATCH 5/7] future/htm: Use \co{} in favor of $$ SeongJae Park
2023-12-02 17:26 ` [PATCH 6/7] future/formalregress: Use \co{} for spin SeongJae Park
2023-12-02 17:26 ` [PATCH 7/7] future/formalregress: Use SEL4 consistently SeongJae Park
2023-12-02 19:29   ` Paul E. McKenney
2023-12-02 21:32     ` SeongJae Park
2023-12-02 23:35       ` Paul E. McKenney

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=20231202172614.20239-2-sj38.park@gmail.com \
    --to=sj38.park@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=perfbook@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.