There are a couple of potential possibilities, here. First, BlockingCollection<T> in the Reactive Extensions is a backport, and not exactly the same as the .NET 4 final version. I wouldn’t be surprised if the performance of this backport differs from .NET 4 RTM (though I haven’t profiled this collection, specifically). Much of the TPL performs … Read more
The accepted solution is, unfortunately, wrong. It is right as far as it says, Kill the connection with lock This is indeed (almost surely; see below) what to do. But then it suggests, Kill 1398 …and 1398 is not the connection with the lock. How could it be? 1398 is the connection waiting for the … Read more
Well blocking IO means that a given thread cannot do anything more until the IO is fully received (in the case of sockets this wait could be a long time). Non-blocking IO means an IO request is queued straight away and the function returns. The actual IO is then processed at some later point by … Read more
That’s a very interesting question, so I did cd into my Go source to start looking. time.Sleep time.Sleep is defined like this: // src/time/sleep.go // Sleep pauses the current goroutine for at least the duration d. // A negative or zero duration causes Sleep to return immediately. func Sleep(d Duration) No body, no definition in … Read more
I found out how to do it. It is not about threads, and not about select(). When I run the first process (grep), it creates two low-level file descriptors, one for each pipe. Lets call those a and b. When I run the second process, b gets passed to cut sdtin. But there is a … Read more
Streams are blocking by default. TCP/IP streams, filesystem streams, pipe streams, they are all blocking. When you tell a stream to give you a chunk of bytes it will stop and wait till it has the given amout of bytes or till something else happens (an interrupt, an end of stream, an error). The operating … Read more
Blocking may or may not be the same as synchronous, depending on the context. When we talk about method calls, then a synchronous call can also be said to be blocking (I’ll get back to this in a bit), because the thread calling the method cannot proceed forward until the method returns. The antonym in … Read more
“Sleeping” You can use numerous constructs that block forever without “eating” up your CPU. For example a select without any case (and no default): select{} Or receiving from a channel where nobody sends anything: <-make(chan int) Or receiving from a nil channel also blocks forever: <-(chan int)(nil) Or sending on a nil channel also blocks … Read more
The code you mention is IMO poorly coded and commented. That code does not conform to POSIX practices for portability as described in Setting Terminal Modes Properly and Serial Programming Guide for POSIX Operating Systems. That code does not mention that it uses non-canonical (aka raw) mode, and reuses the “blocking” and “nonblocking” terminology to … Read more