All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ell@lists.01.org
Subject: Re: [PATCH 6/9] hashmap: Add re-entrancy support to foreach function
Date: Thu, 12 Feb 2015 12:02:41 -0600	[thread overview]
Message-ID: <54DCEAC1.4040406@gmail.com> (raw)
In-Reply-To: <1423725784.4196.6.camel@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 1986 bytes --]

Hi Jukka,

On 02/12/2015 01:23 AM, Jukka Rissanen wrote:
> On ke, 2015-02-11 at 08:06 -0600, Denis Kenzior wrote:
>> Hi Patrik,
>>
>> On 02/11/2015 03:21 AM, Patrik Flykt wrote:
>>> On Tue, 2015-02-10 at 13:47 -0600, Denis Kenzior wrote:
>>>> Can you tell me why this is needed?  This sounds like abuse of
>>>> hashmap_foreach and an alternate data structure might be in order.
>>>
>>> One should not be able to crash the library by (mis)using the provided
>>> API. The implementation needs to work all the time or politely tell that
>>> the API function call did not complete at this time.
>>>
>>
>> Are you serious?  I've yet to see any library that I can't crash by
>> deliberately misusing the API; even the best can't do what you're
>> describing.  Ell's job is not to hand-hold the programmer.
>
> I disagree you here. It is quite difficult to know how ell is being used
> so it should be prepared to not to crash. For example here it is not
> very obvious from the library user point of view that calling
> l_dbus_unregister() from dbus callback will cause a segfault. It is
> clearly a bug that needs to be fixed. I do not understand why we would
> leave this kind of bug in the code and then let the library user to
> invent some workarounds for this issue.
>

Except you're not fixing l_dbus_unregister.  You're fixing l_hashmap, 
which does not need to be 'fixed'.

l_dbus_register used a hashmap for whatever reason.  The reason might 
have been to have a fast O(1) unregister implementation.  But then it 
was not meant to handle re-entrancy in the way you're trying to 
implement it.

I already pointed out to you the long term fix.  We should get rid of 
l_dbus_register completely and add proper signal watch functions with a 
multi-level/tree data structure for fast signal matching.

A stop-gap solution based on gdbus signal watch implementation is also 
acceptable.  But it is only a stop-gap solution.

Regards,
-Denis

  reply	other threads:[~2015-02-12 18:02 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-10 14:42 [PATCH 0/9] hashmap fixes Jukka Rissanen
2015-02-10 14:42 ` [PATCH 1/9] hashmap: Add value free function Jukka Rissanen
2015-02-10 14:42 ` [PATCH 2/9] hashmap: Call user supplied value free function in destroy Jukka Rissanen
2015-02-10 19:07   ` Denis Kenzior
2015-02-10 14:42 ` [PATCH 3/9] hashmap: Call user supplied value free function in insert Jukka Rissanen
2015-02-10 19:18   ` Denis Kenzior
2015-02-11  9:27     ` Patrik Flykt
2015-02-11 11:04       ` Tomasz Bursztyka
2015-02-11 13:50       ` Denis Kenzior
2015-02-10 14:42 ` [PATCH 4/9] unit: hashmap: Add value free hash entry test Jukka Rissanen
2015-02-10 14:42 ` [PATCH 5/9] unit: hashmap: Add replace " Jukka Rissanen
2015-02-10 14:42 ` [PATCH 6/9] hashmap: Add re-entrancy support to foreach function Jukka Rissanen
2015-02-10 19:47   ` Denis Kenzior
2015-02-11  9:21     ` Patrik Flykt
2015-02-11 14:06       ` Denis Kenzior
2015-02-12  7:23         ` Jukka Rissanen
2015-02-12 18:02           ` Denis Kenzior [this message]
2015-02-12  7:25         ` Jukka Rissanen
2015-02-12 17:55           ` Denis Kenzior
2015-02-13 15:38             ` Luiz Augusto von Dentz
2015-02-13 17:04               ` Denis Kenzior
2015-02-13 17:36               ` Marcel Holtmann
2015-02-16  9:44                 ` Luiz Augusto von Dentz
2015-02-16 16:18                   ` Marcel Holtmann
2015-02-16 18:27                     ` Luiz Augusto von Dentz
2015-02-16 19:03                       ` Marcel Holtmann
2015-02-17  9:48                 ` Tomasz Bursztyka
2015-02-17 16:41                   ` Denis Kenzior
2015-02-18  8:23                     ` Tomasz Bursztyka
2015-02-10 14:42 ` [PATCH 7/9] unit: hashmap: Re-entrancy tests added Jukka Rissanen
2015-02-10 14:42 ` [PATCH 8/9] hashmap: Add support to finding an element from hash Jukka Rissanen
2015-02-12  8:35   ` Jukka Rissanen
2015-02-13  0:19     ` Denis Kenzior
2015-02-10 14:42 ` [PATCH 9/9] unit: hashmap: Add unit test for l_hashmap_find Jukka Rissanen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54DCEAC1.4040406@gmail.com \
    --to=denkenz@gmail.com \
    --cc=ell@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.