[concurrency-interest] Fork and and timed get

Oleksandr Otenko oleksandr.otenko at oracle.com
Thu Nov 28 11:04:27 EST 2013

It doesn't promise how long it takes to retrieve the result, though.

(I agree that the user expectation is that the thread management is 
behaving similarly to the promises of the host system - so behaving like 
CPU is contended when it is not, is not expected by the user)


On 28/11/2013 15:24, Romain Colle wrote:
> Hi Doug and all,
> On Wed, Nov 27, 2013 at 8:01 PM, Doug Lea <dl at cs.oswego.edu 
> <mailto:dl at cs.oswego.edu>> wrote:
>     Well, it does meet spec in that it times out no earlier than required.
> As far as I can tell, the javadoc for get(long, TimeUnit) reads: 
> "Waits if necessary for at most the given time for the computationto 
> complete, and then retrieves its result, if available. "
> I would therefore expect it to return no later than when the given 
> timeout has expired.
> On Wed, Nov 27, 2013 at 8:01 PM, Doug Lea <dl at cs.oswego.edu 
> <mailto:dl at cs.oswego.edu>> wrote:
>     Yes. Given the documentation of FJ, people ought to expect this
>     and would claim it to be a bug if it did otherwise. Maybe we
>     should add better method documentation for timed get, and also
>     explain a few ways to get non-participatory timeouts.
>     For example, creating a new thread to perform the invocation
>     and timing out on Thread.join. Suggestions welcome.
> Agreed. However, I'd really like the thread management to be handled 
> by the pool, exactly the way it is done today after trying to help the 
> task in get():
> tryCompensate() / set SIGNAL / wait / incrementActiveCount().
> This is in fact doing exactly the managed block that Viktor suggested.
> Basically what I need is a version of get(long, TimeUnit) that simply 
> does not try to help :-)
> Thanks!
> -- 
> Romain Colle
> R&D Project Manager
> QuartetFS
> 2 rue Jean Lantier, 75001 Paris, France
> http://www.quartetfs.com <http://www.quartetfs.com/>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20131128/6d2431e1/attachment-0001.html>

More information about the Concurrency-interest mailing list