Hi Horiguchi-san,
Thank you for the comment.
I attached the revised patch.
> It looks like too verbose. Couldn't it be summarized as something
> like this?
>
> > Current connection is managed in a per-thread manner. For the first
> > use on a thread, it is the most recently used one in the process.
Yes.
I thought that I needed a detailed explanation of the current connection for the note below, but this certainly seems
tobe summable.
> This doesn't look like a API documentation but a procedual
> documentation. IMO there's no particular reason that we should
> officially concretely suggest how mulitple connectinos are managed on
> somebody's application. And part of the section is already in the
> documentation.
>
> | <para>
> | If your application uses multiple threads of execution, they cannot share a
> | connection concurrently. You must either explicitly control access to the connection
> | (using mutexes) or use a connection for each thread.
> | </para>
>
> So, it would boil down to the caution about disconnection.
>
> > Note that connections are shared among all threads. Be careful not
> > to DISCONNECT a connection that is to be used in another thread.
I wanted to make a document that could avoid the use cases that I reported, so I tried to write a note according to the
occurrenceconditions.
However, this was also too verbose, so I rewrote the note as you suggested.
And since there is no mention of the current connection, I changed the section to add it to "36.2.3. Closing a
Connection".
I think I might be better to add "In the worst case, this may cause an application crash." to this note so that users
canavoid the problem more strongly.
However, this sentence can also be read as claiming that there is an implementation problem.
Should not I add this sentence?
I am also a little concerned that the revised text will be interpreted as prohibiting the following use cases:
> - One thread does all the CONNECT and DISCONNECT commands. Other threads just use the default connection, with mutual
exclusion.
Regards,
Yusuke Egashira
