| Re: [ecf-dev] sendRetrieveRequest blocking |
Hi Scott,
> > <stuff deleted>
> >
> > But it seems the job could also be scheduled before the first
> > request/respnse is made to the server. However this would require
> > the FileTransferJob related information currently passed into
> > IIncomingFileTransferReceiveStartEvent#receive to be made available
> > in some way. I believe this could be done without using non
> > blocking network IO.
> >
>
> Yes, but it would require a provider that can/could make requests
> without blocking (through whatever means...i.e. threading or
> non-blocking i/o, etc).
I am not an eclipse Jobs API expert and I might well be
missing something.
Can you elaborate why it would require non blocking IO?
Could not all potentially blocking calls happen in
another thread so that they do not block the caller that initiates
the request?
This thread would presumably execute the file transfer job.
> <stuff deleted>
> It's possible of course that there is a bug in the socket library, or
> some interaction with a server bug that is preventing the socket from
> not timing out on connect. But it's not obvious to me that this bug is
> resulting from such a situation.
I agree and I am not convinced either.
The point I am trying to make is that the potential for such an issue
will probably cause ECF retrieve api users to initiate file retrievals
from a separate thread.
This would be unecessary if there were no (blocking) network calls
made in the callers thread.
>
> > Cases like this may make callers of the API introduce another
> > thread or job. This would presumably be also needed in situations
> > where cancel needs to works instantly.
> >
>
> What would be such a situation? (i.e. when cancel has to work
> 'instantly'?). Any interprocess communication is going to take some
> measurable time (whether blocking or not), and so what is the usefulness
> of an 'instantaneous' cancel?
What I mean with instantly is that a user should expect the app to react
to cancel from a UI perspective within a second.
The file transfer itself may still be blocked for a bit.
However the transfer job should react to cancel withing a reasonable
period, perhaps a minute. Once it reacts the job would stop using
resources (threads).
Thanks,
Henrich