Comments by <font color="aa7755">parths</font>

parths 23-Oct-13 2:56am View

I thought I'd put it in as a comment (sort of addendum) to your post :). Would it add any value if it were post as a separate solution?

parths 22-Oct-13 6:27am View

I liked the information provided here (http://discrete.gr/complexity/) a lot when I first read it.

parths 12-Jun-13 13:53pm View

I wanted to point out that the assembly listings generated by compilers can actually be viewed.
I learned what little I know about assembly by looking at compiler listings and check google (also a lot by reading Art of Assembly).
Should I have given reference links?

Exactly what kind of explanation would you expect? I'll try to improve my answer.

The behaviour is compiler dependent and theoretically the compiler can actually implement both cases in a similar fashion, right?
For instance _cs$[ebp] seems to indicate the compiler is using an indexed addressing mode (similar to arrays), but it can as well have done something like computing the address, storing in a register and using register indirect addressing. It's not optimal, but theoretically correct, right?

[Modified]I just noticed, nv3 posted a similar explanation. Is that the kind of explanation you are looking for?[/Modified]

parths 15-Apr-13 8:31am View

Thanks for the info. I didn't mean to say anything against using threads with blocking socket io.
Also, thanks for mentioning epoll, didn't know about that. I had checked out IO completion ports on windows for high performance servers, didn't know about epoll, thanks for pointing it out.

parths 15-Apr-13 6:32am View

Just to clarify, I am not against using threads, I had already modified my answer (below) to add that note before continuing our discussion. It'd be informative for me to try and understand any comparisons between the 2 methods. I'm checking google, but if you have any references, please share. Thanks

parths 15-Apr-13 4:19am View

Ref: http://www.xml.com/ldd/chapter/book/ch05.html
FIONBIO sets the O_NONBLOCK flag in filp->f_flags. This results in the read call returning immediately if there's no data present, as opposed to blocking the calling process/thread. This would be necessary if we want to handle multiple connections (or generally io operations) in a single thread without blocking, right?

parths 15-Apr-13 3:13am View

But if we use the same thread for multiple connections, wouldn't each connection in any one thread have to be asynchronous / non-blocking? Otherwise the thread would block on the first blocking call and wouldn't be able to process any other connections that it has. Am I missing something?

parths 15-Apr-13 2:53am View

If we used threading, wouldn't it depend on how many concurrent connections we want to support? For instance, if we have more than about 10-15K connections the context switching between the threads could become a bottleneck, right? Also anything about 32K connections (meaning 32K threads) would probably be unfeasible.

parths 26-Mar-13 3:17am View

Thanks for the excellent set of links. 5'ed!

parths 17-Oct-12 8:36am View

What I was trying to refer to was using something like this (Note: Please don't use the code as is, make sure you check your documentation):

struct sigaction oldAction;
struct sigaction newAction;
newAction.sa_handler = SIG_IGN;
sigemptyset (&newAction.sa_mask);
newAction.sa_flags = 0;
sigaction(SIGPIPE, &newAction, &oldAction); // We can restore the old action later if we want

Also, I'd strongly suggest you revisit Kroki's blog (second link in my original answer) since that solution seems much closer to the SO_NOSIGPIPE that you were looking for.

parths 16-Oct-12 3:15am View

From what I learned from searching google, solaris does not support the SO_NOSIGPIPE. The article in the second link also mentions that some systems do not support SO_NOSIGPIPE. This is most probably the reason SO_NOSIGPIPE is not compiling for you.
In this scenario you can use either of the 2 approaches to
(1) ignore sigpipe altogether for your app using sigaction
(2) catch and suppress sigpipe from your send as described in the blog post linked above.

parths 9-Feb-11 3:27am View

Deleted

Interesting, although I couldn't check it out since it seems to be supported for Windows Vista and above. I'm on XP.

Comments by parths (Top 12 by date)