Doubt about sockets

[Eric Norum]

On Jun 22, 2010, at 12:29 PM, Vinu Rajashekhar wrote:

> On Wed, Jun 23, 2010 at 12:34 AM, Eric Norum <wenorum at lbl.gov> wrote:
> 
> On Jun 22, 2010, at 10:49 AM, Vinu Rajashekhar wrote:
> 
>> On Tue, Jun 22, 2010 at 10:44 PM, Eric Norum <wenorum at lbl.gov> wrote:
>> Why not just use the message queues that RTEMS provides?
>> It seems like a lot of extra work to go through the network stack for this.
>> 
>> I am not working on C code directly. I am a student currently working
>> on the GSoC project of porting gccgo, the gcc frontend to Go into RTEMS.
>> 
>> The problem is with a network library component of Go. The code is in Go. This 
>> part of the library provides functionality for handling nonblocking sockets efficiently. 
>> They basically put all the nonblocking sockets into a set, and poll the set to see if 
>> any one is ready. In linux, they used epoll, but since RTEMS doesn't have it, we 
>> have to use select.
>> 
>> As part of this support we need to wakeup select when we have to add a new socket
>> into the set. So what they used is a pipe, and the read end of the pipe would go into
>> the set of fds, that epoll/select is polling on. So if we want to wakeup select, we can
>> just write something into the pipe. The problem here in RTEMS is, we can't use pipes,
>> because select can't wait on them. So we thought of using sockets, that is when the original
>> doubt of using the same socket for writing in multiple threads came up.
>> 
>> So I hope you are clear on the context in which this problem came up ?
>> 
>> So, if writing into the same socket from different threads is not a problem in waking up
>> select, then I can safely use that. I don't care about the data transferred using the socket.
>> Are there better solutions than this ? 
> 
> If you want to retain as much of the existing code in the project then this sounds reasonable.
> 
> Yes, that is the aim ofcourse.
> 
> I would suggest that you add a global mutex and obtain it just before the write and release it just after.  Then you can be sure that you don't have multiple threads attempting to write at the same time.
> 
>  
> Well, as I said, we do not care if that happens, if select wakes up because of any one of those
> writes. 
I'm not 100% sure that two tasks writing to the same socket descriptor at the same time is safe.
The underlying sendmsg routine that all the various transmit functions (write, send, sendto) call does take the network semaphore and is thus fine to call from multiple threads at the same time, but I've not looked through the paths that  write() takes to get to sendmsg to ensure that all that code is thread-safe.

>> 
>> I was asking about socketpairs() because, if it is possible, I can add that function,
>> into RTEMS, as part of my work.
>> 
> 
> I was hoping to get some answer on this, because implementing this using socketpair(), would
> be a much better option. 

I don't recall why I left socketpair out when I ported the FreeBSD network stack to RTEMS.   Maybe it would not be too hard to add it, but I make no guarantees about this.

-- 
Eric Norum
wenorum at lbl.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20100622/b689de5d/attachment.html>