Doubt about sockets

Tue Jun 22 19:29:03 UTC 2010

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

> 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/20100623/d55219df/attachment-0001.html>