question about the user supplied executor

[peter hausel]

Hi,

quick question about the user supplied executor:

as Joe indicated here: https://groups.google.com/forum/#!msg/webbit/Vr_MN9CwNsA/oaiidfkNv6wJ the assumption is that webbit is single-threaded, therefore the user supplied executor also should provide only a single thread. While this makes perfect sense to me, this criterium does mean that the usefulness of the  supplied executor is fairly limited (after all, it's very unlikely in practice that an app that bundles webbit would be able to effectively share a  thread-pool of size 1 with webbit).  On the other hand it's a constant source of confusion (https://github.com/webbit/webbit/pull/109 and https://groups.google.com/d/msg/webbit/Vr_MN9CwNsA/VXYCZbtDoxAJ), since there is no simple way to enforce this requirement (as far as I know). 

So my question is, what's the benefit of being able to use an external executor that's limited to use only a single thread? (And also, If it's not that useful, would not make sense to deprecate the corresponding factory methods in `WebServers` to avoid the confusion?)

Please let me know your thoughts.

Cheers,

Peter

 

[aslak hellesoy]

If you pass it in, you can submit other jobs to the same executor because now you have a reference to it. This is useful for example if you want to send something to a web socket or event source when some external event occurs.

Here is an example: https://github.com/webbit/webbit/blob/master/src/test/java/samples/eventsource/Main.java

Another use case is when you want to use a single-threaded executor with some special behaviour, for example a jetlang[1] fiber

Does that answer your question?

Aslak

 

[1] https://code.google.com/p/jetlang/

Please let me know your thoughts.

Cheers,

Peter

 

--
You received this message because you are subscribed to the Google Groups "Webbit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webbit+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Joe Walnes]

I use this functionality when combined with other libraries. For example, I also use Jetlang <http://code.google.com/p/jetlang/>, a library which allows you to build Erlang style message passing systems in Java - in this case, I'd like to ensure that my Jetlang Fiber and Webbit handlers always share the same execution thread.

I have no objection to the API changing, if there's a strong motivation, so long as we retain the functionality to pass in an executor via some other mechanism.

 

--

[peter hausel]

Thank you both for your explanations!  Please see my comments below

On Wednesday, February 27, 2013 10:40:17 AM UTC-5, Joe Walnes wrote:

I use this functionality when combined with other libraries. For example, I also use Jetlang <http://code.google.com/p/jetlang/>, a library which allows you to build Erlang style message passing systems in Java - in this case, I'd like to ensure that my Jetlang Fiber and Webbit handlers always share the same execution thread.

I see - using it with an actor lib can make sense, indeed! My point was that the majority of the java libraries/frameworks out there are synchronous/blocking which would not work out well in an embedded, shared thread-pool setup (and I can imagine folks would jump to the wrong conclusion after seeing the `executor` constructor in `WebServers`)

I have no objection to the API changing, if there's a strong motivation, so long as we retain the functionality to pass in an executor via some other mechanism.

Perhaps another solution to reduce the confusion could be to print out a message to the console when Webbit is invoked this way (something along this line "webbit is  invoked with a custom executor XYZ. It's assumed this executor is providing only a single-thread.) 

[peter hausel]

On Wednesday, February 27, 2013 10:34:42 AM UTC-5, Aslak Hellesøy wrote:

On Wed, Feb 27, 2013 at 3:20 PM, peter hausel <peter....@gmail.com> wrote:

Hi,

quick question about the user supplied executor:

as Joe indicated here: https://groups.google.com/forum/#!msg/webbit/Vr_MN9CwNsA/oaiidfkNv6wJ the assumption is that webbit is single-threaded, therefore the user supplied executor also should provide only a single thread. While this makes perfect sense to me, this criterium does mean that the usefulness of the  supplied executor is fairly limited (after all, it's very unlikely in practice that an app that bundles webbit would be able to effectively share a  thread-pool of size 1 with webbit).  On the other hand it's a constant source of confusion (https://github.com/webbit/webbit/pull/109 and https://groups.google.com/d/msg/webbit/Vr_MN9CwNsA/VXYCZbtDoxAJ), since there is no simple way to enforce this requirement (as far as I know). 

So my question is, what's the benefit of being able to use an external executor that's limited to use only a single thread? (And also, If it's not that useful, would not make sense to deprecate the corresponding factory methods in `WebServers` to avoid the confusion?)

If you pass it in, you can submit other jobs to the same executor because now you have a reference to it. This is useful for example if you want to send something to a web socket or event source when some external event occurs.

Here is an example: https://github.com/webbit/webbit/blob/master/src/test/java/samples/eventsource/Main.java

I see - although this could be also achieved by exposing the internal executor (in which case the single threaded thread-pool is guaranteed by webbit).

 

Another use case is when you want to use a single-threaded executor with some special behaviour, for example a jetlang[1] fiber

That's a good point. It's just easy to jump to the wrong conclusion IMHO - considering that most java libs/frameworks that could embed webbit are synchronous.

 

Does that answer your question?

Yes - thank you.

Cheers,

Peter