Doubt about sockets

Tue Jun 22 19:04:21 UTC 2010

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.
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.

> 
> I was asking about socketpairs() because, if it is possible, I can add that function,
> into RTEMS, as part of my work.
> 
> On Jun 22, 2010, at 10:04 AM, Vinu Rajashekhar wrote:
> 
>> On Tue, Jun 22, 2010 at 10:11 PM, Eric Norum <wenorum at lbl.gov> wrote:
>> 
>> On Jun 22, 2010, at 9:21 AM, Vinu Rajashekhar wrote:
>> 
>>> On Tue, Jun 22, 2010 at 9:48 PM, Eric Norum <wenorum at lbl.gov> wrote:
>>> You can read and write a socket from different threads.
>>> Just don't have multiple threads trying to read at the same time or trying to write at the same time.
>>> 
>>> 
>>> Yes, what if that happens, I don't care about the data being transferred.
>>> I just want to wakeup select using the socket, then ?
>> 
>> Are you doing a select waiting for read data to appear?
>> or are you doing a select waiting for space to become ready in a write queue?
>> 
>> Do you mean you do a write on one machine and want the 'select read' to wake up on the other machine?
>> 
>> It's not clear to me what you have in mind.
>> 
>>  
>> Ok. What I need to do is to wakeup a select call, that's all, on the same machine.
>> 
>> The original code, had a pipe whose read end would go into the set of fds in select.
>> But with RTEMS, since select can't wait on file descriptors, I can't use this. I can't
>> use socketpairs in place of the pipe, by the way, since RTEMS doesn't support that.
>> 
>> So the solution is to use a plain sockets. I will write something into one socket, sw, 
>> which should wakeup select, because it would be waiting on the socket at the other
>> end of the connection, socket sr. Basically replicating something like a pipe, but I don't
>> care about the data, just need to wakeup the select.
>> 
>> Now, this write into sw, can happen from more than one thread, at the same time.
>>  that is a potential problem in RTEMS. So what is the solution for this problem ? 
>> Is there a better solution to my problem ?
>> 
>> As an aside, is implementing socketpairs() in RTEMS very difficult at this point in time ?
>>>  
>>> On Jun 22, 2010, at 9:03 AM, Vinu Rajashekhar wrote:
>>> 
>>> > From the networking documentation, it seems that one cannot
>>> > share the same socket across threads/tasks for the same operation, like
>>> > read or write.
>>> >
>>> > What is the exact problem if I use the same socket to write something
>>> > across different threads, is data corruption the only problem? More specifically,
>>> > if I have run a select call on a socket, and if I write something into the socket,
>>> > from different threads, does the select wakeup for sure ?
>>> > _______________________________________________
>>> > rtems-users mailing list
>>> > rtems-users at rtems.org
>>> > http://www.rtems.org/mailman/listinfo/rtems-users
>>> 
>>> --
>>> Eric Norum
>>> wenorum at lbl.gov
>>> 
>>> 
>> 
>> -- 
>> 
>> Eric Norum
>> wenorum at lbl.gov
>> 
>> 
> 
> -- 
> 
> Eric Norum
> wenorum at lbl.gov
> 
> 

-- 
Eric Norum
wenorum at lbl.gov

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