DragonFly users List (threaded) for 2013-04
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: Porting sbcl to DragonFly
--bcaec54eebba4270bc04db1e99e0
Content-Type: text/plain; charset=ISO-8859-1
2013/4/21 Markus Pfeiffer <markus.pfeiffer@morphism.de>
> Hi,
>
> On Sat, Apr 13, 2013 at 12:14:15AM +0400, vasily postnicov wrote:
> > I've started sourceforge project, where I put sbcl-1-1.6 patched for
> DragonFly.
> > I almost gave up fixing threads support, so it is switched off by now.
> >
> > Here is pkgsrc package (based on original lang/sbcl):
> > http://shamazmazum.users.sourceforge.net/sbcl.tar
> >
> > Can anyone upload it to DragonFly's pkgsrc tree? I can maintain this
> package
> > and send new versions on regular basis.
>
> Out of interest: What stops threads from working? Is it a DragonFly issue
> or
> is it just that SBCLs thread model is not easily ported?
>
> Markus
>
Playing with commenting lines out. The latest thing I found is this:
There is perform_thread_post_mortem function inside
path_to_sbcl/src/runtime/thread.c
>static void*
>perform_thread_post_mortem(struct thread_post_mortem *post_mortem)
>{
>#ifdef CREATE_POST_MORTEM_THREAD
> pthread_detach(pthread_self());
>#endif
> if (post_mortem) {
> gc_assert(!pthread_join(post_mortem->os_thread, NULL));
> gc_assert(!pthread_attr_destroy(post_mortem->os_attr));
> free(post_mortem->os_attr);
> // NOTE NEXT LINE
> os_invalidate(post_mortem->os_address, THREAD_STRUCT_SIZE);
> free(post_mortem);
> }
> return NULL;
>}
If you remove call of os_invalidate, SBCL works without crashes.
os_invalidate is opposing/freeing call after we os_validate
thread->os_address. os_validate/os_invalidate are wrappers for mmap/munmap
and can be found in path_to_sbcl/src/runtime/bsd-os.c
os_validate is called in create_thread_struct. There is a note on this:
> /* May as well allocate all the spaces at once: it saves us from
> * having to decide what to do if only some of the allocations
> * succeed. SPACES must be appropriately aligned, since the GC
> * expects the control stack to start at a page boundary -- and
> * the OS may have even more rigorous requirements. We can't rely
> * on the alignment passed from os_validate, since that might
> * assume the current (e.g. 4k) pagesize, while we calculate with
> * the biggest (e.g. 64k) pagesize allowed by the ABI. */
> spaces=os_validate(0, THREAD_STRUCT_SIZE);
> if(!spaces)
> return NULL;
> /* Aligning up is safe as THREAD_STRUCT_SIZE has
> * THREAD_ALIGNMENT_BYTES padding. */
> aligned_spaces = (void *)((((uword_t)(char *)spaces)
> + THREAD_ALIGNMENT_BYTES-1)
> &~(uword_t)(THREAD_ALIGNMENT_BYTES-1));
Still have no idea why sometimes it works and sometimes crashes.
--bcaec54eebba4270bc04db1e99e0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">2013/4/21 Markus Pfeiffer <span dir=3D"ltr"><<a href=3D"mailto:m=
arkus.pfeiffer@morphism.de" target=3D"_blank">markus.pfeiffer@morphism.de</=
a>></span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<div><div class=3D"h5"><br>
On Sat, Apr 13, 2013 at 12:14:15AM +0400, vasily postnicov wrote:<br>
> I've started sourceforge project, where I put sbcl-1-1.6 patched f=
or DragonFly.<br>
> I almost gave up fixing threads support, so it is switched off by now.=
<br>
><br>
> Here is pkgsrc package (based on original lang/sbcl):<br>
> <a href=3D"http://shamazmazum.users.sourceforge.net/sbcl.tar"; target=
=3D"_blank">http://shamazmazum.users.sourceforge.net/sbcl.tar</a><br>
><br>
> Can anyone upload it to DragonFly's pkgsrc tree? I can maintain th=
is package<br>
> and send new versions on regular basis.<br>
<br>
</div></div>Out of interest: What stops threads from working? Is it a Drago=
nFly issue or<br>
is it just that SBCLs thread model is not easily ported?<br>
<span class=3D""><font color=3D"#888888"><br>
Markus<br>
</font></span></blockquote></div><br></div><div class=3D"gmail_extra">Playi=
ng with commenting lines out. The latest thing I found is this:<br><br></di=
v><div class=3D"gmail_extra">There is perform_thread_post_mortem function i=
nside path_to_sbcl/src/runtime/thread.c<br>
<br>>static void*<br>>perform_thread_post_mortem(struct thread_post_m=
ortem *post_mortem)<br>>{<br>>#ifdef CREATE_POST_MORTEM_THREAD<br>>=
;=A0=A0=A0 pthread_detach(pthread_self());<br>>#endif<br>>=A0=A0=A0 i=
f (post_mortem) {<br>
>=A0=A0=A0=A0=A0=A0=A0 gc_assert(!pthread_join(post_mortem->os_thread=
, NULL));<br>>=A0=A0=A0=A0=A0=A0=A0 gc_assert(!pthread_attr_destroy(post=
_mortem->os_attr));<br>>=A0=A0=A0=A0=A0=A0=A0 free(post_mortem->os=
_attr);<br></div><div class=3D"gmail_extra">
>=A0=A0=A0=A0=A0=A0=A0 // NOTE NEXT LINE<br></div><div class=3D"gmail_ex=
tra">>=A0=A0=A0=A0=A0=A0=A0 os_invalidate(post_mortem->os_address, TH=
READ_STRUCT_SIZE);<br>>=A0=A0=A0=A0=A0=A0=A0 free(post_mortem);<br>>=
=A0=A0=A0 }<br>>=A0=A0=A0 return NULL;<br>>}<br>
<br></div><div class=3D"gmail_extra">If you remove call of os_invalidate, S=
BCL works without crashes. os_invalidate is opposing/freeing call after we =
os_validate thread->os_address. os_validate/os_invalidate are wrappers f=
or mmap/munmap and can be found in path_to_sbcl/src/runtime/bsd-os.c<br>
<br></div><div class=3D"gmail_extra">os_validate is called in create_thread=
_struct. There is a note on this:<br><br>>=A0=A0=A0 /* May as well alloc=
ate all the spaces at once: it saves us from<br>>=A0=A0=A0=A0 * having t=
o decide what to do if only some of the allocations<br>
>=A0=A0=A0=A0 * succeed. SPACES must be appropriately aligned, since the=
GC<br>> =A0 =A0 * expects the control stack to start at a page boundary=
-- and<br>>=A0=A0=A0=A0 * the OS may have even more rigorous requiremen=
ts. We can't rely<br>
>=A0=A0=A0=A0 * on the alignment passed from os_validate, since that mig=
ht<br>>=A0=A0=A0=A0 * assume the current (e.g. 4k) pagesize, while we ca=
lculate with<br>>=A0=A0=A0=A0 * the biggest (e.g. 64k) pagesize allowed =
by the ABI. */<br>>=A0=A0=A0=A0 spaces=3Dos_validate(0, THREAD_STRUCT_SI=
ZE);<br>
>=A0 =A0=A0 if(!spaces)<br>> =A0 =A0=A0=A0=A0=A0=A0 return NULL;<br>&=
gt;=A0=A0=A0 /* Aligning up is safe as THREAD_STRUCT_SIZE has<br>>=A0=A0=
=A0=A0 * THREAD_ALIGNMENT_BYTES padding. */<br>>=A0=A0=A0 aligned_spaces=
=3D (void *)((((uword_t)(char *)spaces)<br>
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 + THREAD_ALIGNMENT_BYTES-1)<br>>=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 &=
~(uword_t)(THREAD_ALIGNMENT_BYTES-1));<br><br></div><div class=3D"gmail_ext=
ra">Still have no idea why sometimes it works and sometimes crashes.<br>
</div></div>
--bcaec54eebba4270bc04db1e99e0--
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
