These discussions degrade quickly.
I'm not proposing using pread() on a socket. I was
pointing out that you can do two concurrent pread()
invocations on the same file descriptor (for a file)
and get consistent results. It would be nice if you
can do two concurrent sendmsg() invocations on the
same
Benjamin Reed wrote:
In the case of lseek() and read(), you can use
pread().
What is the meaning of the offset parameter of pread() for TCP or UDP etc?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
You are using the wrong examples, which may be why you
don't understand the problem Mark identified.
--- Christopher Friesen <[EMAIL PROTECTED]> wrote:
> There have always been possible issues with
> concurrent access to
> sockets/fds.
>
> Or consider calling lseek() from one task, while
> doing
Benjamin Reed wrote:
I think Mark's point isn't about "atomic" writes;
instead, he was pointing out that when a programmer
reads that a call is thread-safe he usually
understands that to mean that it does not need to be
protected by a lock when used by multiple threads.
This thread-safe iss
David et al, I think you may be missing the point.
David S. Miller wrote:
> I don't understand why the desire is so high to
> ensure that individual threads get "atomic" writes,
> you can't even ensure that in the general case.
I think Mark's point isn't about "atomic" writes;
instead, he was po
On Mon, May 15, 2006 at 06:50:36PM -0700, Mark A Smith wrote:
>
> I cannot think of another possible definition for thread-safe in the
> context of these functions. Certainly they should not cause a "crash" when
> called from multiple threads, but that's a requirement independent of
> thread-safet
|
| To: Mark A Smith/Almaden/[EMAIL PROTECTED]
|
| cc: [EMAIL PROTECTE
Mark A Smith wrote:
Hi Rick, Stephen,
The thread-safe claim is at:
http://devrsrc1.external.hp.com/STKS/cgi-bin/man2html?manpage=/usr/share/man/man2.Z/send.2
Specifically,
"
MULTITHREAD USAGE
The send(), sendmsg(), and sendto() system calls are thread-safe.
They each have a cancel
I presume this is only for "blocking" sockets? I cannot at least off
the top of my head see how a stack could offer it on non-blocking sockets.
The test seems to be based on sending a big message. In this case,
on non-blocking sockets, the send call will return partial status. The
return from
On Mon, 15 May 2006 16:17:48 -0700
Rick Jones <[EMAIL PROTECTED]> wrote:
> David S. Miller wrote:
> > From: Mark A Smith <[EMAIL PROTECTED]>
> > Date: Mon, 15 May 2006 14:39:06 -0700
> >
> >
> >>I discovered that in some cases, send(), sendmsg(), and sendto() are not
> >>thread-safe. Although th
David S. Miller wrote:
From: Mark A Smith <[EMAIL PROTECTED]>
Date: Mon, 15 May 2006 14:39:06 -0700
I discovered that in some cases, send(), sendmsg(), and sendto() are not
thread-safe. Although the man page for these functions does not specify
whether these functions are supposed to be thread
From: Mark A Smith <[EMAIL PROTECTED]>
Date: Mon, 15 May 2006 14:39:06 -0700
> I discovered that in some cases, send(), sendmsg(), and sendto() are not
> thread-safe. Although the man page for these functions does not specify
> whether these functions are supposed to be thread-safe, my reading of
12 matches
Mail list logo
