5 ms·
A separate thread? I assume that's all the kernel would be doing anyway, no ring zero magic involved.
by dooglius 7y ago
A separate thread? I assume that's all the kernel would be doing anyway, no ring zero magic involved.
- mehrdadn 7y agoA debugger stops every thread though?
- dooglius 7y agoFair point, I was more addressing the blocking-call concern. There are a number of ways you could get your debugger of choice to not halt a particular thread (this would admittedly require some extra work), but won't a typical browser have an application-level timeout that you'd hit anyway.
- mehrdadn 7y agoBrowser? I'm not talking about browsers, I'm talking about every other kind of application that tries to use a userland protocol, because that seems to be the direction network libraries are aiming to go. I have no idea how to tell most (all?) debuggers not to halt particular threads, but it sounds painful. And my point is, there are consequences like this that no one seems to care about at all, but that I would hope would've been addressed before seeing people jump on the ship.
- beagle3 7y agoTCP keep alive has a minimum of 2 hours or so. Debugging can live with that. And debugger ruins everything; If the other side sends something larger than the local receive buffer it will usually disconnect after a while. as it will sense no one on the other end. All the things that debugger can "ruin" should just be parametric - increase buffer sizes / keep alive times when debugging. Also, there are more options than "kernel" and "each process for themselves" - you could have a "network/TCP daemon". QNX successfully does that for disk drivers and file system drivers - and likely network too. So does Minix. It's just that historically, unix/linux/NT don't.
- mehrdadn 7y ago> TCP keep alive has a minimum of 2 hours or so. Debugging can live with that. If the "minimum" was 2 hours then e.g. MSDN wouldn't be recommending that it be configured to 5 minutes would it? https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd349797(v=ws.10) https://docs.microsoft.com/en-us/previous-versions/windows/i... > And debugger ruins everything; If the other side sends something larger than the local receive buffer it will usually disconnect after a while. as it will sense no one on the other end. "Everything"? Well when data isn't being sent then the connection could live on as long as it's kept alive by the kernel, right? Whereas with a userland implementation even that possibility becomes difficult. You seem really intent on making unfounded blanket claims to rebut my point... but I feel like there's some validity to the point I'm making? It's be more helpful to see if you can instead find parts of it that might have some truth to them. > It's just that historically, unix/linux/NT don't. Yeah, hence why this approach seems problematic...