• Jonathan (6/6) Mar 26 2018 Can I send data over an std.socket on multiple threads without
• bauss (13/19) Mar 26 2018 Define thread safe.
• Jonathan (6/28) Mar 26 2018 You answered what I needed.
• Dmitry Olshansky (19/25) Mar 26 2018 It’s thin-wrapper over system interface.

Jonathan <JonathanILevi gmail.com> writes:

Can I send data over an std.socket on multiple threads without 
manual mutexing?

If not, can I send data on a separate thread than receive?

The docs for std.socket say nothing of it (which I guess means I 
should assume it is not thread safe but...).

Thanks!

bauss <jj_1337 live.dk> writes:

On Monday, 26 March 2018 at 16:14:31 UTC, Jonathan wrote:
 Can I send data over an std.socket on multiple threads without 
 manual mutexing?

 If not, can I send data on a separate thread than receive?

 The docs for std.socket say nothing of it (which I guess means 
 I should assume it is not thread safe but...).

 Thanks!

Define thread safe.

It's safe in the way that the buffers each call to send will have 
will be what you expect.

Ex.

thread1 sends [1,2,3] and thread2 sends [4,5,6]

then you're guaranteed that what you receive would be [1,2,3] and 
[4,5,6].

What it isn't safe from would be race conditions.

So you don't know if you get it like [1,2,3,4,5,6] or 
[4,5,6,1,2,3].

So if the order of the buffer matters then you should use a 
mutex, but if the order doesn't matter then you don't need to.

Jonathan <JonathanILevi gmail.com> writes:

On Monday, 26 March 2018 at 17:55:10 UTC, bauss wrote:
 On Monday, 26 March 2018 at 16:14:31 UTC, Jonathan wrote:
 Can I send data over an std.socket on multiple threads without 
 manual mutexing?

 If not, can I send data on a separate thread than receive?

 The docs for std.socket say nothing of it (which I guess means 
 I should assume it is not thread safe but...).

 Thanks!

 Define thread safe.

 It's safe in the way that the buffers each call to send will 
 have will be what you expect.

 Ex.

 thread1 sends [1,2,3] and thread2 sends [4,5,6]

 then you're guaranteed that what you receive would be [1,2,3] 
 and [4,5,6].

 What it isn't safe from would be race conditions.

 So you don't know if you get it like [1,2,3,4,5,6] or 
 [4,5,6,1,2,3].

 So if the order of the buffer matters then you should use a 
 mutex, but if the order doesn't matter then you don't need to.

You answered what I needed.

The order of receiving the messages is not a problem, merely that 
a message its self is not broken, ie: [4,1,2,5,3,6](This would 
not work!)

Thanks!

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

On Monday, 26 March 2018 at 16:14:31 UTC, Jonathan wrote:
 Can I send data over an std.socket on multiple threads without 
 manual mutexing?

 If not, can I send data on a separate thread than receive?

 The docs for std.socket say nothing of it (which I guess means 
 I should assume it is not thread safe but...).

It’s thin-wrapper over system interface.

It’s thread-safe in that system will not topple over, you will 
likely get some interleaving of data.

HOWEVER: there is such a thing as short-writes, which means that 
since OS buffer may fill up it could write less then you intended 
to and return that amount. It certainly happens with O_NONBLOCK.
In normal blocking mode it might work, but in general it’s a bad 
idea to do writes to a single socket from multiple threads w/o 
some coordination s.t. only can do it at any given time.

Lastly as far as guarantees go, POSIX doesn’t state that 2 writes 
will be interleaved “exactly”, it may for instance splice them 
zebra-style by some chunk size and I could imagine why (on long 
buffers).

My suggestion is to have a queue of messages and a thread to send 
them. You might also want to check and see if there is a better 
protocol then TCP to take advantage of unordered messages. I 
think there is at least RDP (reliable datagram protocol) on Linux 
that might fit the bill.

 Thanks!