Doubt about sockets

Vinu Rajashekhar vinutheraj at
Tue Jun 22 17:49:33 UTC 2010

On Tue, Jun 22, 2010 at 10:44 PM, Eric Norum <wenorum at> 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.
part of the library provides functionality for handling nonblocking sockets
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
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 ?

I was asking about socketpairs() because, if it is possible, I can add that
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> 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> 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
>>> >
>>> --
>>> Eric Norum
>>> wenorum at
>>  --
>> Eric Norum
>> wenorum at
> --
> Eric Norum
> wenorum at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list