headers
Gábor Melis | 1 Jan 2009 21:53
Picon

Re: Data printed to pipe sometimes comes out twice

On Viernes 19 Diciembre 2008, Rudi Schlatte wrote:
> On 19.12.2008, at 20:33, Gábor Melis wrote:
> > On Viernes 19 Diciembre 2008, Tim Cooijmans wrote:
> >> I have two threads that communicate through a two-way pipe.  This
> >> mostly works, but sometimes I get weird buggy behaviour, where
> >> something that's written into the pipe comes out twice at the
> >> other end.
> >>
> >> Attached is a minimal test case.  The main thread reads from stdin
> >> and prints whatever is read to a pipe.  The other thread reads
> >> from the other end of the pipe and prints whatever comes out. 
> >> Feed it some input and you might see the second thread read the
> >> same input twice.
> >>
> >> What could cause this?  My code looks good to me.  Thread-safety
> >> shouldn't matter because the threads never read from or print to
> >> the same streams simultaneously (right?).  Can anyone reproduce
> >> this or is it just me?
> >>
> >> Thanks,
> >>
> >> Tim
> >
> > I think it ought to be fine, however it fails here, as well.
> >
> > The root of the problem is that the two way stream itself will, for
> > some
> > reason, flush its OUT each time its IN is read (!), hence the
> > internal buffer is modified concurrently by two threads.
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Leslie P. Polzer | 9 Jan 2009 10:31
Picon

Shared locks


Hi,

it should be enough to lock a hash table shared between
multiple threads when a write is in progress.

Using a mutex however would make readers block each
other, too.

How can I block only when a write is in progress?

  Thanks!

    Leslie

--

-- 
LinkedIn Profile: http://www.linkedin.com/in/polzer
Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
Blog: http://blog.viridian-project.de/

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
Permalink | Reply | 1 comment |
headers
Nikodemus Siivola | 9 Jan 2009 10:41
Gravatar

Re: Shared locks

On Fri, Jan 9, 2009 at 11:31 AM, Leslie P. Polzer
<sky <at> viridian-project.de> wrote:

> it should be enough to lock a hash table shared between
> multiple threads when a write is in progress.

In practice this is currently true, yes, but this is not in any way
guaranteed: implementation details may change, and that can mean that
concurrent reads are future-proof safe.

> Using a mutex however would make readers block each
> other, too.
>
> How can I block only when a write is in progress?

You need to roll a read-write lock. (Yes, it would be nice for SBCL to
provide one.)

Cheers,

 -- Nikodemus

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
Permalink | Reply | 0 comments |
headers
karol skocik | 9 Jan 2009 18:19
Picon
Gravatar

CLOS sealing declarations

Hi,
  I would like to optimize our application written with several SBCL
specific things already baked in, so I am looking for SBCL specific
options for speeding up mainly CLOS slot access. Juho mentioned on
#lisp a possibility to add sealing declarations. How do I tell SBCL
that I want to seal a class that won't be redefined or subclasses
later in run-time?
Thanks,
  Karol

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
Permalink | Reply | 3 comments |
headers
Nikodemus Siivola | 10 Jan 2009 11:20
Gravatar

Re: CLOS sealing declarations

On Fri, Jan 9, 2009 at 7:19 PM, karol skocik <karol.skocik <at> gmail.com> wrote:

> I would like to optimize our application written with several SBCL
> specific things already baked in, so I am looking for SBCL specific
> options for speeding up mainly CLOS slot access. Juho mentioned on
> #lisp a possibility to add sealing declarations. How do I tell SBCL
> that I want to seal a class that won't be redefined or subclasses
> later in run-time?

The declamation you are looking for is

  (declaim (sb-ext:freeze-type foo))

except that it doesn't really help: it doesn't prevent class
redefinitions, and it doesn't help optimize slot-access.

Are you familiar with the performance discussion in

  http://www.sbcl.org/manual/Slot-access.html#Slot-access

?

If you need slot accesses with speeds beyond the "slot-value with
constant second argument in defmethod body" described there, you can
use a custom metaclass to provide a :LOCATION argument for slots,
orders the slots based on that in COMPUTE-SLOTS, and use
STANDARD-INSTANCE-ACCESS to access them -- but beating the best-case
slot-value speed is pretty hard, since it has extra support in the
method dispatch machinery.
(Continue reading)

Permalink | Reply | 2 comments |
headers
karol skocik | 10 Jan 2009 20:28
Picon
Gravatar

Re: CLOS sealing declarations

Hi,
  thanks for clarification,

>  (declaim (sb-ext:freeze-type foo))
>

I will follow advice 3. along with others and rewrite our most
performance sensitive classes as structs, so I guess this declamation
can't hurt then.

>  http://www.sbcl.org/manual/Slot-access.html#Slot-access
>

I missed that in manual, thanks for the link.

> Other tricks to speed up your slot access performance:
>
> 1. If you need fast slot-accesses in a DEFUN for some reason (?),
> define a multi-value accessor method:
>
>  (defmethod values-for-foo ((x bar) (y zot) (z quux))
>   (values (slot-value x 'a)
>           (slot-value y 'b)
>           (slot-value z 'c)))
>
> This allows you to get the fast slot accesses for the slots you need
> and pay for the dispatch only one. Most of the time you are better of
> using a DEFMETHOD instead of the DEFUN instead, though -- but if
> you're not receiving the instances whose slots you are interested in
> as arguments, this may be worthwhile.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nikodemus Siivola | 11 Jan 2009 11:38
Gravatar

Re: CLOS sealing declarations

On Sat, Jan 10, 2009 at 9:28 PM, karol skocik <karol.skocik <at> gmail.com> wrote:
> Hi,
>  thanks for clarification,
>
>>  (declaim (sb-ext:freeze-type foo))
>>
>
> I will follow advice 3. along with others and rewrite our most
> performance sensitive classes as structs, so I guess this declamation
> can't hurt then.

It won't really help either -- it will only change the way TYPEP test
for frozen types are compiled slightly, without any real performance
advantage. Add to that the fact that if/when proper inheritance
sealing is implemented, the FREEZE-TYPE declamation is likely to be
deprecated, I would recommend against using it.

Cheers,

 -- Nikodemus

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
Permalink | Reply | 0 comments |
headers
Nikodemus Siivola | 11 Jan 2009 15:51
Gravatar

Re: Possible SAP memory leak

On Wed, Dec 31, 2008 at 10:22 PM, Simon Handley <shandley_42 <at> yahoo.com> wrote:
> I'm trying to track down a possible memory leak associated with SAPs, and
> I'm hoping that someone else has already seen this and I've just stupidly
> missed an obvious solution in the list archives.

I'm 90% sure that (most of?) the leak your test exhibits is actually
caused by test itself: without your code you can see that the test
conses quite a bit itself. I'm thinking that when your code is loaded
it simply conses even more, and some things end up inopportunely
tenured -- and finally you run out of space.

Looking at the generation breakdown I'm thinking that (GC :GEN 2)
after MAP-ALLOCATED-OBJECTS should be sufficient to unkink this.

(What you are seeing is the result of an unfortunate combination of
issues in MAP-ALLOCATED-OBJECTS and the generational GC.)

Additionally, I would strongly suggest passing T as the third argument
to MAP-ALLOCATED-OBJECTS.

Cheers,

 -- Nikodemus

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
(Continue reading)

Permalink | Reply | 501 comments |
headers
Nikodemus Siivola | 11 Jan 2009 15:52
Gravatar

Re: Possible SAP memory leak

On Sun, Jan 11, 2009 at 4:51 PM, Nikodemus Siivola
<nikodemus <at> random-state.net> wrote:
> On Wed, Dec 31, 2008 at 10:22 PM, Simon Handley <shandley_42 <at> yahoo.com> wrote:
>> I'm trying to track down a possible memory leak associated with SAPs, and
>> I'm hoping that someone else has already seen this and I've just stupidly
>> missed an obvious solution in the list archives.

Oh, by the by: plain text messages are *strongly* preferred.

> Cheers,
>
>  -- Nikodemus

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
Permalink | Reply | 0 comments |
headers
Nikodemus Siivola | 15 Jan 2009 09:36
Gravatar

Re: What defines a successful build?

On Sun, Dec 14, 2008 at 2:00 PM, Nikodemus Siivola
<nikodemus <at> random-state.net> wrote:
> On Sun, Dec 14, 2008 at 4:37 AM, Daniel Jomphe <amis <at> danieljomphe.name> wrote:
>
>> I just fetched SBCL's sources and built them. I ended up with a warning that
>> the posix-related contrib module hadn't been able to be built. The REPL
>> seems to work fine. I ran the tests and got the following. Can I conclude my
>> setup has a problem?
>
> Seems like it. The problems with the test suite probably have the same
> core issue as SB-POSIX. You can rebuild just the contribs with

Just to keep the list posted: I've been helping Daniel diagnose this,
and we've narrowed down the proximate cause: some parts of the system
call his home directory /Users/Username and others /Users/username --
which results (somehow, not yet sure about the details) in SBCL
initializing *DEFAULT-PATHNAME-DEFAULTS* using one, and DIRECTORY
canonicalizing the results using the other. ...which in turn causes
ENOUGH-NAMESTRING to fail to unparse results from DIRECTORY against
*D-P-D*, breaking the SB-POSIX test READDIR/DIRENT-NAME.

(I assume failures in the regular test suite to have similar pathologies.)

Cheers,

 -- Nikodemus

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
(Continue reading)

Permalink | Reply | 0 comments |

Gmane