From: Mikhail Kruk <meshko@cs.brandeis.edu>
To: David Schwartz <davids@webmaster.com>
Cc: linux-kernel@vger.kernel.org
Subject: RE: fcntl file locking and pthreads
Date: Sun, 4 May 2003 15:29:04 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.44.0305041518530.14517-100000@calliope.cs.brandeis.edu> (raw)
In-Reply-To: <MDEHLPKNGKAHNMBLJOLKKEHKCLAA.davids@webmaster.com>
> > CLONE_FILES is an argument to clone(), I'm using pthreads and I don't
> > know if LinuxThreads implementation of pthreads gives me control of
> > how clone is called. Anyway, if I understand what CLONE_FILES does,
> > it should be given to clone, because threads do have to be able
> > to share file
> > descriptors, probably. But not the locks!
>
> What if I have an application where requests are written to files. Thread A
> comes along and notices a job in a file, so it locks the file and reads the
> job. The job will require some network I/O, so the thread goes on to do
> other things. Later on, thread B notices the network I/O has completed, so
> it needs to write to the file, release the lock, and close the file.
I am not persuaded by this example. Why didn't thread A close the file
when it finished the network I/O? That would be logical time to do it. If
it wasn't a file descriptor, but a shared memory region, would you argue
the same about a mutex protecting that memory region?
I think this should not be a question of personal opinions or specific
examples. It should just be consistent. Two reference platforms for
threads are Solaris and Windows. I don't know how Solaris handles this,
but on Windows file locks are per thread, not per process.
[Please cc]
next prev parent reply other threads:[~2003-05-04 19:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-04 6:13 fcntl file locking and pthreads Mikhail Kruk
2003-05-04 12:58 ` Jamie Lokier
2003-05-04 13:25 ` Mikhail Kruk
2003-05-04 15:24 ` Miquel van Smoorenburg
2003-05-04 18:40 ` David Schwartz
2003-05-04 19:29 ` Mikhail Kruk [this message]
2003-05-04 20:55 ` David Schwartz
2003-05-04 21:50 ` Mikhail Kruk
2003-05-04 21:29 ` Mark Mielke
2003-05-04 21:56 Ville Voutilainen
2003-05-04 22:04 ` Mikhail Kruk
2003-05-04 22:29 Ville Voutilainen
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=Pine.LNX.4.44.0305041518530.14517-100000@calliope.cs.brandeis.edu \
--to=meshko@cs.brandeis.edu \
--cc=davids@webmaster.com \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).