Re: [riot-devel] Condition Variables
Thanks for the advice, Simon, Martin, and Kaspar! For now, I'll use a mutex together with thread_flags. Using message passing, as Simon suggested, would work for me as well; the reason I find thread_flags preferable is that I need to block application threads that call send() and receive(), that may already be using message passing. If people don't mind, and they think it would be useful, I'm also willing to contribute a lightweight condition variable to the core module. I think it could be implemented simply as a queue, just like the current mutex implementation. Sam On Wed, Aug 17, 2016 at 10:19 AM, Kaspar Schleiser <kas...@schleiser.de> wrote: > Hey, > > On 08/16/2016 09:49 PM, Sam Kumar wrote: > > If not, I want to learn if there is another structured way to > > block a thread until an event, that I should use instead. > > maybe thread_flags work for your use-case. > > Kaspar > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Socket #0
Hi Martine,
I will work on testing it with sock and PR #6004, but it may take some time
since I might need to port the interface from conn to sock.
It seems to me that conn is deprecated and that sock is its replacement
moving forward. Am I correct? And what is the motivation for moving away
from conn?
Sam
On Thu, Jan 12, 2017 at 4:43 AM, Martine Lenders <m...@martine-lenders.eu>
wrote:
> Hi Sam,
> can you try with PR #6004 which ports POSIX sockets from conn to sock?
> There are still some kinks in this PR, but I plan to fix them until the
> release. On another note: the conn implementation of sockets was never
> tested with TCP (since there was no TCP implementation then), but feel free
> to test (and hopefully fix) any issues in that PR.
>
> Cheers,
> Martine
>
> [1] https://github.com/RIOT-OS/RIOT/pull/6004
>
> 2017-01-12 12:15 GMT+01:00 Sam Kumar <samkuma...@gmail.com>:
>
>> Hello,
>> I've been doing some work with the conn API for a TCP stack that I've
>> been developing. I noticed that on line 238 of posix_sockets.c (
>> https://github.com/RIOT-OS/RIOT/blame/master/sys/posix/sock
>> ets/posix_sockets.c#L238), in the socket_close() function, the
>> comparison to test whether a socket number can be closed is:
>>
>> if ((unsigned)(socket - 1) > (SOCKET_POOL_SIZE - 1)) {
>> return -1;
>> }
>>
>> I noticed that if the socket number is 0, then socket_close() will always
>> fail. Is socket 0 a special socket that can't be closed? The problem I'm
>> having is that a call to socket() sometimes returns 0, and I'm unable to
>> close that socket due to this issue.
>>
>> Sam Kumar
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Socket #0
Hello, I finally got around to porting my implementation to use sock instead of conn. I am running into a similar issue now. It seems this check is still in sock (see https://github.com/RIOT-OS/RIOT/blame/master/sys/posix/sockets/posix_sockets.c#L237 ). I think that the check should be: assert(0 <= socket && socket < _ACTUAL_SOCKET_POOL_SIZE); but perhaps there is some reasoning behind the original check that I am not aware of. Could someone more familiar with the sock code please take a look? Thanks, Sam On Thu, Jan 12, 2017 at 5:19 AM, Martine Lenders <m...@martine-lenders.eu> wrote: > Hi Sam, > > 2017-01-12 14:06 GMT+01:00 Sam Kumar <samkuma...@gmail.com>: > >> Hi Martine, >> I will work on testing it with sock and PR #6004, but it may take some >> time since I might need to port the interface from conn to sock. >> It seems to me that conn is deprecated and that sock is its replacement >> moving forward. Am I correct? >> > > That is correct, conn was deprecated with our 2016.10 release and its > deprecation was widely advertised within the community before its > deprecation. > > >> And what is the motivation for moving away from conn? >> > > As you might have noticed conn is both quite ugly to use and to implement. > sock aimed to simplify a lot of these usage issues we had in conn. And also > fix quite a few bugs conn had in the backend in most implementations. > > Cheers, > Martine > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
