Interesting project. Can you expand on any differences or similarities with core.async's pipeline, pipeline-async, etc ?
https://clojuredocs.org/clojure.core.async/pipeline On Sun, Sep 12, 2021 at 5:30 AM 'Tsutomu YANO' via Clojure < clojure@googlegroups.com> wrote: > Hi clojurians, > > We publish our library for concurrent processing of data with core.async. > named 'concurrently' > > https://github.com/uzabase/concurrently > > > With 'concurrently', programmers can create shared process-pipelines > backed by core.async and > can share the pipelines safely/easily from multiple requester-threads. > > Shared pipeline can accepts requests from many requester-threads and > handle the requests in > shared concurrent pipeline of core.async and then split the calculated > results to each requesters. > > Using core.async for creating shared pipeline causes many difficulties for > programmers because: > > * Shared channels easily stack, because if some requester threads stop > reading a channel for > accidental exceptions, some data remain unread and nobody can write the > channel. it might > causes a shared pipeline stops (stacks) for waiting to write data to the > unread channel. > * You must carefully handle channels as they NEVER stack. > * All input-data are put onto a same pipeline and you must SPLIT data from > output of the shared pipeline > in any way for returning the processed results to each > requester-threads. > > > 'concurrently' handles all the problems described above. > Each requster-threads just pass input-data by calling a 'concurrently' > functions. Shared pipeline will return a 'Job', > then Each requster-threads can get all calculated results for the > input-data by calling 'get-results' function on the job. > No verbose tasks for protecting channels from accidental stack or > splitting calculated results for each requesters. > > > UZABASE is a company based on Japan that is processing/publishing > financial data on SaaS applications, > and uses Clojure language for many tasks. > > This 'concurrently' library is made for our streaming-data-processing > tasks and already is used for over 1 year. > Problems of this library are found and already are fixed while the long > application on real tasks, > So we decided to publish this library for many programmers. > > We hope that it is useful for someone. > > Thank you. > > > > Tsutomu YANO > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clojure/47D5CA02-79AA-4267-9EFA-4B63D415957D%40me.com > <https://groups.google.com/d/msgid/clojure/47D5CA02-79AA-4267-9EFA-4B63D415957D%40me.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/CAPo-QOsZ8WQRZkKvEsMzx1_c68a93e9eMZRaZgzuf_0i_ziQDQ%40mail.gmail.com.
