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
next prev parent 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.