Fork me on GitHub

thanks @noisesmith and @hiredman, I will look into both options


I would like to have the ability to pause the process in-between the files getting processed, so that once an abort command is issued (or triggered via Ctrl-C) it will finish any IO operations that are currently running, but won't start any new ones


but perhaps I can figure out how to do that with an Executor and ExecutorCompletionService


Hello all, I have a question about core.async. I have one function that get http information from website. Sometimes the response don´t comeback. Is there any way to handle a timeout with clojure-async?


the http lib has timeout but even with timeout don´t comeback, so I would try to use core-async to avoid not returning


@fabrao yes -- looks at alts!!/`alts!` if you call (async/alts!! [some-chan (async/timeout 1000)]) it will return a vector of the form [value channel]. If value is nil then it means either some-chan closed or the 1 second timeout occurred


Thanks, I´ll take a look


How can I resolve an async channel and assoc the result to an map?


I have a process which parses and xml file, and writes the data to an atom, this is put onto a channel which is returned. When I use a go block to receive the data from the channel, i don't now, how to save it into a map.


@danielgrosse I don't quite understand -- what is the format of the data being put into the channel? can you not just put a map into the channel? sorry, I don't follow


I wrote an question to SO, as I assume the problem on another part of the code.


@ghadi following up on something from beginners that didn’t belong in that channel any more - I made this version of core.async/thread in order to be able to cancel the thread created, and it seems to behave OK. Any suggestions for making a test that would provoke the bad behavior you mention?


perhaps the fact that the future-cancel is only done when the channel is closed would help prevent the cancelation-inside-thread-lock issue you warned of


but I’d rather have proof or disproof than speculate 😄


hypothesis: make the body be a loop that interacts with a channel / channels repeatedly but before doing that expose the thread externally somehow


then interrupt the thread from the outside


alternative to exposing the thread from the inside out is to (def a Thread.) and always use it


the code I shared above cancels the task (created because it uses submit) but only inside channel methods


otherwise it doesn’t expose the thread


well - it has it as a slot, I guess that’s exposure


the bug will be visible when using a channel inside the threads body


it is unrelated to CancelableThreadChan


OK, so my root worry was that what you were saying about cancellation and breaking things would mean that this code was a ticking time bomb (I’d like to either prove it’s broken or that I can keep using it)


maybe it would be less likely to hit an issue if I did the channel close / cleanup / abort type things before the canceling of the thread