OS context switch

[Jawahar Muthukrishnan]

Scenario:
Assume a scenario where there are a large number of threads waiting for CPU time. The OS is serving a thread which has established a socket connection with a remote client. The remote client has started transferring a large file through the connection.
Question:
If the time required to transfer the file through the socket is longer than the context-switch time of the OS (pre-emptive scheduling) like Windows, will the OS do a context-switch??? If it does, what happens to the REMOTE client which is in the middle of transferring data??? Will there be any data loss??
Thanks
Jawahar

[Jim Yingst]

If the time required to transfer the file through the socket is longer than the context-switch time of the OS (pre-emptive scheduling) like Windows, will the OS do a context-switch???
Yes, probably. I suspct that even with preemtive scheduling, there's a certain atomicity of actions, and thread management can't or won't cut things off too abruptly. When a tread is pre-emted, it must be able to save its state well enough that it can resume later without ill effects (other than a slight delay).
If it does, what happens to the REMOTE client which is in the middle of transferring data??? Will there be any data loss??
There shouldn't be any data loss - this is fairly standard usage of threads, I have to assume either the OS or the JVM is designed to handle it, or they wouldn't be able to claim to have implemented a JVM on that OS. Since a JVM is required to bea able to implement threads according to the JLS and JVM specs, which don't allow for threads which just randomly drop data. The remote client may observe some pauses in transmission of data, but that's normal - the client doesn't know or care whether delays are caused by something on the server, or in the network. It just waits until it has recieved enough data to process, then it processes the data. Usually there's a loop where it waits for an EOF or other signal (depending what protocol you're using).