Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #34783 > unrolled thread

: Light Weight Channels Lib anybody

Back to article view | Back to comp.lang.java.programmer

Contents

  : Light Weight Channels Lib anybody Jan Burse <janburse@fastmail.fm> - 2016-07-08 11:42 +0200
    Re: : Light Weight Channels Lib anybody Daniel Pitts <usenet@coloraura.com> - 2016-07-08 08:36 -0700
      Re: : Light Weight Channels Lib anybody Jan Burse <janburse@fastmail.fm> - 2016-07-08 19:17 +0200
        Re: : Light Weight Channels Lib anybody Daniel Pitts <usenet@coloraura.com> - 2016-07-08 10:25 -0700
        Re: : Light Weight Channels Lib anybody Jan Burse <janburse@fastmail.fm> - 2016-07-08 19:27 +0200
        Re: : Light Weight Channels Lib anybody Marcel Mueller <news.5.maazl@spamgourmet.org> - 2016-07-09 10:41 +0200
          Re: : Light Weight Channels Lib anybody Martin Gregorie <martin@address-in-sig.invalid> - 2016-07-09 10:46 +0000
    Re: : Light Weight Channels Lib anybody j4n bur53 <janburse@fastmail.fm> - 2016-07-09 17:43 +0200
      Re: : Light Weight Channels Lib anybody j4n bur53 <janburse@fastmail.fm> - 2016-07-09 17:44 +0200
        Re: : Light Weight Channels Lib anybody Jan Burse <janburse@fastmail.fm> - 2016-07-09 18:17 +0200

#34783 — : Light Weight Channels Lib anybody

Dear All,

Does somebody know about a light weight channels
Java library, where I can select/wait both on read
and writes on a channel as is possible in Golang:

http://stackoverflow.com/questions/19992334/how-to-listen-to-n-channels-dynamic-select-statement

Bye

[toc] | [next] | [standalone]

#34793

On 7/8/16 2:42 AM, Jan Burse wrote:
> Dear All,
>
> Does somebody know about a light weight channels
> Java library, where I can select/wait both on read
> and writes on a channel as is possible in Golang:
>
> http://stackoverflow.com/questions/19992334/how-to-listen-to-n-channels-dynamic-select-statement
>
>
> Bye

I just so happen to have created such a thing myself a while back:

https://github.com/StochasticTinkr/net.virtualinfinity.nio

Note that Golang has different semantics than Java, so you can't do a 
one-to-one translation.

[toc] | [prev] | [next] | [standalone]

#34795

Interesting. Small question before I go deeper in your code, is
your code supposed to be a variant of:
https://docs.oracle.com/javase/7/docs/api/java/nio/channels/Selector.html

Because I consider this not as light weight, rather heavy
weight, since it uses the OS channels. Also delegates to
the OS poll.

I would like to use some very simple home grown pipes(*)
as channels, and don't need to support something else
as channels.

Bye

(*)
http://www.jekejeke.ch/idatab/doclet/blog/en/docs/05_run/01_kernel/misc/Queue.html

Daniel Pitts schrieb:
> I just so happen to have created such a thing myself a while back:
>
> https://github.com/StochasticTinkr/net.virtualinfinity.nio
>
> Note that Golang has different semantics than Java, so you can't do a
> one-to-one translation.

[toc] | [prev] | [next] | [standalone]

#34797

On 7/8/16 10:17 AM, Jan Burse wrote:
> Interesting. Small question before I go deeper in your code, is
> your code supposed to be a variant of:
> https://docs.oracle.com/javase/7/docs/api/java/nio/channels/Selector.html
>
> Because I consider this not as light weight, rather heavy
> weight, since it uses the OS channels. Also delegates to
> the OS poll.
>
> I would like to use some very simple home grown pipes(*)
> as channels, and don't need to support something else
> as channels.
Yes, my code uses the Selector class.

I think I misunderstood your original question, which I think maybe is 
about same-process communication.   There are *many* ways to do that 
with Java.  PipeInputStream and PipeOutputStream are one way.  The 
java.util.concurrent package has a lot of other ways to efficiently pass 
data between threads as well.


>
> Bye
>
> (*)
> http://www.jekejeke.ch/idatab/doclet/blog/en/docs/05_run/01_kernel/misc/Queue.html
>
>
> Daniel Pitts schrieb:
>> I just so happen to have created such a thing myself a while back:
>>
>> https://github.com/StochasticTinkr/net.virtualinfinity.nio
>>
>> Note that Golang has different semantics than Java, so you can't do a
>> one-to-one translation.
>

[toc] | [prev] | [next] | [standalone]

#34798

Jan Burse schrieb:
> Interesting. Small question before I go deeper in your code, is
> your code supposed to be a variant of:
> https://docs.oracle.com/javase/7/docs/api/java/nio/channels/Selector.html

Oh, I see it makes use of the Java Selector class:

public final class EventLoop implements Closeable {
     private final Selector selector;

Well, this is a kill criteria, it should be a OS-less reimplementation,
without any poilling under the hood or extra threads. But a
change in the channel implementation is allowed, they can be
re-implemented from scratch, and only need to support pipes.

Bye

[toc] | [prev] | [next] | [standalone]

#34818

On 08.07.16 19.17, Jan Burse wrote:
> Because I consider this not as light weight, rather heavy
> weight, since it uses the OS channels. Also delegates to
> the OS poll.

Well, you won't come around to involve the OS if you do not want to be 
stuck with spin-locks that raise the over all entropy. ;-)

> I would like to use some very simple home grown pipes(*)
> as channels, and don't need to support something else
> as channels.

And how do you want to block while waiting for several channels to 
become ready?

Using notify/wait in your implementation creates condvars for each 
object which is also not that light wight. Depending on the OS this 
creates a set of mutex and event semaphore. And it requires many 
synchonisations and context switches.
So in fact every thing depends on your definition of light-wight.


Marcel

[toc] | [prev] | [next] | [standalone]

#34819

On Sat, 09 Jul 2016 10:41:00 +0200, Marcel Mueller wrote:

> On 08.07.16 19.17, Jan Burse wrote:
>> Because I consider this not as light weight, rather heavy weight, since
>> it uses the OS channels. Also delegates to the OS poll.
> 
> Well, you won't come around to involve the OS if you do not want to be
> stuck with spin-locks that raise the over all entropy. ;-)
>
I've used the poll() function in C programs on both UNIX (on a DEC 
alphaserver) and Linux servers, with the former using it throughout a 
high performance, high volume multi-process system in preference to a 
multi-threading approach. Performance was even better than I expected, so 
if poll() is heavy-weight in the sense of 'slow', then that wasn't 
apparent.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#34833

A solution from scratch turned out pretty simple. Just
introduce an underground layer of publish - subscribe.

Each channels falls into a source and a sink, and the
select block temporarily subscribes to its cases.

Currently doing some final testing and round some
corners such as interrupted waits cleanup.

Can post a link to the source code later.

Jan Burse schrieb:
> Dear All,
>
> Does somebody know about a light weight channels
> Java library, where I can select/wait both on read
> and writes on a channel as is possible in Golang:
>
> http://stackoverflow.com/questions/19992334/how-to-listen-to-n-channels-dynamic-select-statement
>
>
> Bye

[toc] | [prev] | [next] | [standalone]

#34834

j4n bur53 schrieb:
> A solution from scratch turned out pretty simple. Just
> introduce an underground layer of publish - subscribe.

The select is just an or-condition on the subscribed
publishers. Now figure out what needs to be done.

[toc] | [prev] | [next] | [standalone]

#34835

But very annoyingly the Go rselect, which can be read
as "run select" but I guess it could also be read as
"randomized select", requires shuffling the cases, even
for each invocation I guess.

And shuffling requires access to a random generator,
which might need some additional locking probably.
So after all I have the impression that the Go rselect
is not extremly simple.

Also I am not sure about the application scenarios,
those I have seen so far could be also solve with single
queue or even single priority queue. Just force your M:1
producer consumers to write into the same queue.

What could be an application scenario though, could
be something along 1:M producer consumer arbitration.

Still experimenting.

Bye

j4n bur53 schrieb:
> j4n bur53 schrieb:
>> A solution from scratch turned out pretty simple. Just
>> introduce an underground layer of publish - subscribe.
>
> The select is just an or-condition on the subscribed
> publishers. Now figure out what needs to be done.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web