[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] sendRetrieveRequest blocking
|
Hi Henrich,
Henrich Kraemer wrote:
<stuff deleted>
> 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?
Yes. That's why I listed 'threading' as one of the means. This could
easily be with a job.
This thread would presumably execute the file transfer job.
Not sure if this is really feasible, as usually the job manager executes
jobs...but I get the point.
> <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.
Right, but two points: 1) I don't think the potential is very high. 2)
Even if the potential is higher than I expect, the API users can do this
(i.e. use another thread).
This would be unecessary if there were no (blocking) network calls
made in the callers thread.
True.
>
> > 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.
OK.
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).
OK. Like I said, this seems fine to me, but at least for me it doesn't
rise to a high level of importance ATM (unless evidence arises that
Socket.connect is never timing out when it should be).
Scott
