Doubt about sockets

[Vinu Rajashekhar]

On Wed, Jun 23, 2010 at 1:12 AM, Eric Norum <wenorum at lbl.gov> wrote:

>
> 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.
>
>
Another doubt. Can I use unix domain sockets in RTEMS ? I get an unknown
protocol
error when using AF_UNIX.

>
>> 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.
>
>
Ok. Thanks!

-- 
>
> Eric Norum
> wenorum at lbl.gov
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20100623/385eab9e/attachment.html>