closer changed the topic of #ruby-core to: check the latest release candidate for 1.9.1 release ftp.ruby-lang.org:/home/yugui/ruby-1.9.1-r26021+1.tar.bz2
hsbt has quit [Quit: Tiarra 0.1+svn-39209: SIGTERM received; exit]
hsbt has joined #ruby-core
hsbt is now known as hsbt_away
hsbt_away is now known as hsbt
hsbt is now known as hsbt_away
hsbt_away is now known as hsbt
hsbt is now known as hsbt_away
hsbt_away is now known as hsbt
<znz_jp>
biff: [ruby-changes:41129] ngoto:r53202 (trunk): * enc/windows_1250.c: Should not use C++ style comments (C99 feature). - http://mla.n-z.jp/?ruby-changes=41129
akshayvishnoi has joined #ruby-core
charliesome has joined #ruby-core
charliesome has quit [Client Quit]
akshayvishnoi has quit [Quit: akshayvishnoi]
charliesome has joined #ruby-core
charliesome has quit [Client Quit]
akshayvishnoi has joined #ruby-core
_ko1 has joined #ruby-core
<_ko1>
@headius hi
<headius>
_ko1: Hi there..I think I understand, you have the same concern
<headius>
e.g. we can't do a lock-free queue in the future
<_ko1>
a bit different.
<headius>
that was what raised the concern for me...we were using such a lock-free queue as our implementation and can't use it anymore
<_ko1>
i'm not sure we can make lock-free queue, but at least we can't use Java's current lock-free queue.
<_ko1>
i agree.
<_ko1>
you wrote: "Performance seems fine"
<_ko1>
try with benchmarks?
<headius>
I have only done quick tests but it looks ok...better in fact
<headius>
that may be because lock-free impl is allocating more objects behind the scenes
<_ko1>
i see.
<headius>
let me run another test
<headius>
SizedQueue is implemented with an array in Java so it would be lighter
<_ko1>
maybe on many threads it is different.
<_ko1>
s/on/with/
<_ko1>
i understand your concern, and we need to decide we should revert it or should not for 2.3.
<_ko1>
btw, API concers, we can postpone.
<_ko1>
i believe 99% of use cases, they use nil for termination.
<headius>
that may be
<_ko1>
configurable options can be added after 2.4 or later.
<headius>
the additional pop forms could be 2.4
<_ko1>
however, we can't remove Queue#close after release.
<_ko1>
(or difficult to become it obsolete)
<headius>
sized form seems ok on performance too
<headius>
it may be because the lock-free queues can't provide num_waiting so I had to implement that separately
<_ko1>
i see.
<headius>
I say it is ok for 2.3
<_ko1>
it -> SizedQueue?
<headius>
Queue#close and current behavior
<headius>
I would like to see a way to pop and get closed status in the future but we don't have time to add that
<headius>
so my issue can be moved to 2.4 I think
<_ko1>
you mean about API concerns?
<_ko1>
> a way to pop and get closed status
<headius>
yes
<_ko1>
ok. i also don't worry about that. I only worry about performance you pointed out.
<_ko1>
i missed this pont.
<headius>
I can't show performance problem right now
<_ko1>
point
<headius>
I will keep testing today
<headius>
do you have any Queue performance tests?
<_ko1>
sorry, nothing.
<_ko1>
as you said, we need to support parallel behavior and checking close bit is weired
<headius>
yes
<headius>
I'm sorry I did not see this earlier...we didn't have time to look at new features until preview1
<_ko1>
no proble, thank you so much pointing out
<_ko1>
we have one week until 2.3 release :)
<headius>
I may look at Go channel code today too
<_ko1>
i'm not sure but they can use global locking.
<_ko1>
for each channel.
<_ko1>
because channels are used for 1 to 1 communication.
<headius>
closed uint32
<_ko1>
it can do N to M communication, but most of users use 1 to 1.
<headius>
yeah
<headius>
lock(&c.lock)
<headius>
they lock on channel
<headius>
but they do have some fast path checks before locking