Please change the name to that of yours, and adjust copyright year to the date when you wrote or modified the code (in this case it should be 2017).

I would like to have your name printed on the source code (as well as on the README if your work gets merged).

I appreciate your kindness.
I fixed it here: 60f1d0e

How about retaining the queue in mruby side, while restricting use of the C code to when signalling between fibers is necessary?

I believe that doing so would simplify the code and will give us more flexibility in extending the object (for example, it would be easier to add a peek method).

class Channel
  def initialize()
    @queue = []
  end
  def push(o)
    @queue << o
    self._notify
  end
  def shift
    while true
      if !@queue.empty?
        return @queue.shift
      end
      self._wait
    end
  end
  // _notify and _wait are C methods that are called via fiber switching
end

I agree this idea, because it's a little complex to deal with queue in C.
Then I fixed it like below. (I'll add rb file and use script to create embedded code soon.)
064a44b

・For _h2o__channel_wait, it seems we can't call fiber yield ruby code from C, then I wrote to call _h2o__channel_wait directly.
・For initializing Channel object, maybe there is better or more simple way, then I'm willing to fix it.

duplicated definition with L185?

I deleted duplicated definition.
792f3f1

How about defining normal initialize method and move these code into that? If so, you can simply call H2O::Channel.new instead of defining and calling _init method. Then if you still want handy create_channel method under Kernel, you can define it by using H2O::Channel.new (but IMO it's not so useful)

I fixed to define normal initialize method for initializing channel.
4c17ebd

Could you elaborate why this is needed? I haven't understand the purpose for this clearly, but it seems to be something wrong for me

When creating task like this:
task { http_request(req_url).join; ch.push "hello"; http_request(req_url).join; }

channel_notify_method calls h2o_mruby_run_fiber, and sets current_context NULL in this h2o_mruby_run_fiber.
And after h2o_mruby_run_fiber, it continues processing task block, but current_context is NULL, then http_request_method cannot get current_context.

I think another way is not setting current_context NULL if it's call by channel_notify_method.
If there are other better way, please tell me. I'll fix it.

The most straightforward solution might be doing like this in h2o_mruby_run_fiber:

h2o_mruby_context_t *old = ctx->shared->current_context;
ctx->shared->current_context = ctx;
/* ... */
ctx->shared->current_context = old;

But in my thoughts, it's better to eliminate nested h2o_mruby_run_fiber call. How about using yield to switch fibers and use the run loop in h2o_mruby_run_fiber function instead of nested calls?

I tried to use yield to switch fibers and use the run loop in h2o_mruby_run_fiber, but it says
mruby raised: (eval):5: can't cross C function boundary (FiberError)
It seems impossible to yield from mruby->C->mruby.
If my understanding about this is not correct, please tell me.
Or I'll fix to use straightforward solution above.

Sorry for very trivial point, but I feel that it's clearer and safer to remove while loop.
After the fiber gets resumed, it's guaranteed that @queue variable is not empty, so how about the following code?

def shift
  if @queue.empty?
    _h2o__channel_wait(self)
  end
  raise 'oops' if @queue.empty?
  @queue.shift
end

I fixed not to use needless loop.
82fa91d

How about simply returns [0, nil, nil] instead of yield ?

I fixed to simply returns [0, nil, nil]
ea711f5

Please let me ask some questions around here:

• What does klass means? For example, in channel usage, fiber_res[2][0] seems to be H2O::Channel 's instance, not class.
• Is it guaranteed that the klass object respond_to? :register_receiver ? I mean that many asynchronous functions can be called in task block, and HTTP response body streaming is one of the examples. So if I understand correctly, http_request(..).join[2].join fails (but sorry I haven't tried)
• When the block yileds (calls defined callback method), there may be some args (i.e. fiber_res[2][1], fiber_res[2][2]..) How to handle that?

What does klass means? For example, in channel usage, fiber_res[2][0] seems to be H2O::Channel 's instance, not class.

I think we use klass for instance name in ruby usage. If others is better, I'll fix it.
https://stackoverflow.com/questions/4299289/what-is-the-difference-between-class-and-klass-in-ruby

Is it guaranteed that the klass object respond_to? :register_receiver ? I mean that many asynchronous functions can be called in task block, and HTTP response body streaming is one of the examples. So if I understand correctly, http_request(..).join[2].join fails (but sorry I haven't tried)

It's not guaranteed and we must create register_receiver when we create new class having async function. (I forgot to add for HttpInputStream, then I added here.)
aa53e90

When the block yileds (calls defined callback method), there may be some args (i.e. fiber_res[2][1], fiber_res[2][2]..) How to handle that?

sorry, I realized h2o_mruby_http_fetch_chunk_callback are using args other than self in new code now.
How about this idea?:

1. move parts using args to new function named reserved word like process_args(args)
2. If there are some value on args other than self(index 0) in async function, call process_args(args)
3. do same thing for task function calling process_args(args)

For example, In case of _h2o__http_fetch_chunk,

1. move this(https://github.com/h2o/h2o/blob/master/lib/handler/mruby/http_request.c#L463-L471) from h2o_mruby_http_fetch_chunk_callback to new function process_args, and call process_args
2. In task function, if there is common same named function process_args.

In this way, we don't have to create branch in task function like mruby_run_fiber because of using same named function, but we have to care when we add function using args.

Isn't it possible to use self for some reason?

I had mistakes, I fixed it to use self.
6316078

this begin ~ rescue is not necessary?

I deleted begin ~ rescue
7a05215

The most straightforward solution might be doing like this in h2o_mruby_run_fiber:

h2o_mruby_context_t *old = ctx->shared->current_context;
ctx->shared->current_context = ctx;
/* ... */
ctx->shared->current_context = old;

But in my thoughts, it's better to eliminate nested h2o_mruby_run_fiber call. How about using yield to switch fibers and use the run loop in h2o_mruby_run_fiber function instead of nested calls?

This seems to leak. You have to free this in on_gc_dispose_channel

I fixed to free ctx and check null of values of that.
05790cd

H2O_MRUBY_CALLBACK_ID_CHANNEL_WAIT might be better name?

I fixed to use name H2O_MRUBY_CALLBACK_ID_CHANNEL_WAIT
36f718e

it's better to use mrb_data_check_get_ptr instead of DATA_PTR macro, or at least be consistent

I fixed to use mrb_data_check_get_ptr
69a4baf

JFYI, you don't have to call skip_all multiple times

I deleted needless skip_all
8f4c9bf

H2O::Channel.new?

I fix to use new for creating instances.
7edafbc

I would appreciate if you could add the tests which joins response body :D

I added a test for that.
250acdd

Sorry I forgot to remove this check and goto. I introduced _h2o__finish_child_fiber, so this is no longer needed. Could you remove this?

Would you mind elaborating what happens if block.call raises an exception? My expectation is that h2o__finish_child_fiber() will not be called in such case.

If calling h2o__finish_child_fiber() makes any difference, then I believe that we should call the function even if block.call raises an error. Or if h2o__finish_child_fiber() is a noop, can we eliminate the function?

For now, entire application will stop when block.call raises.
Then I fixed to call _h2o__send_error and not to call _h2o__finish_child_fiber intentionally.
52ea223
By this, task will raise an error and only task dies but parent application will not stop when fiber in task raises.
If this design is wrong and I should make it parent application stop when task raises, I'll fix it.

perfect! :D

Could you please elaborate how we ensure that a Channel will have at most one listeners?

I couldn't find code that provides such guarantee, and wonder what happens if two fibers call shift of one channel object.

PS. Please note that I am not suggesting that we should support multiple readers. Supporting only one reader is fine, but an error in mruby script should be reported as an mruby exception; not an abrupt termination of the server process.

I fixed to raise error when shift is called though it's already registered.
2cf40c2

@naritta Would you mind supporting multiple listener (shifter)? Discussed with @kazuho today, it may be useful in minor cases and can be easily implemented .

To implement that, simply do:

• change receiver to receivers (Array)
• use mrb_ary_push instead of attach_receiver
• use mrb_ary_shift instead of detach_receiver

How do you feel?

Sounds cool. I fixed to support multiple listener like above.
916cab1

Do we need to call mrb_gc_unregister(mrb, ctx->receiver)?

I believe that the question boils down to if there is a chance in GC collecting the channel object while a receiver is being attached to a object; and to me, something like below seems to trigger such condition:

task {
  H2O::Channel.new.shift
}

I fixed to call mrb_gc_unregister.
da33b13

Could you add a check that ensures ctx->receiver is not nil? i.e. if (!mrb_nil_p(ctx->receiver))

I fixed to check if ctx->receiver is not nil before mrb_gc_unregister .
4312b53

At this time we definitely set receivers in initialization, so this nil check you newly added is no longer needed. Sorry for the confusion 😵

Sorry, I forgot to check it. I deleted it.
03c0a42