Resolver hang

fraca7 · Post by **fraca7** » Sun Mar 04, 2007 9:20 pm

Hello. I've got a problem when resolving a name to an IP address (using the net/resolver sample); it happens to hang quite often when calling sceNetResolverStartNtoA.

Searching the forums turned one thread of discussion but the only answer didn't do the trick for me (upgrade pspsdk; I'm using the latest SVN version).

Any hint ?

TIA

fraca7 · Post by **fraca7** » Sat Mar 10, 2007 8:39 pm

This seems to be fixed if I add sceNetResolverStop() in gethostbyname. Should I commit the fix ? Who's "in charge" of newlib ?

monsti · Post by **monsti** » Sun Mar 11, 2007 12:38 am

fraca7 wrote:This seems to be fixed if I add sceNetResolverStop() in gethostbyname. Should I commit the fix ? Who's "in charge" of newlib ?

Send the patch - I'll add it to 1.1.15.

monsti · Post by **monsti** » Sun Mar 11, 2007 3:28 am

Ok this is patched in the newlib.1.15.0.patch in the toolchainn SVN.

raf · Post by **raf** » Tue Mar 13, 2007 12:11 am

monsti wrote:Ok this is patched in the newlib.1.15.0.patch in the toolchainn SVN.

I see in the patch file that gethostbyaddr is now calling sceNetResolverStop(). But gethostbyname is still not doing it.. Was that on purpose?
Also, I believe you should commit the changes to the newlib-psp directory, not only to the patch file. As now they are out-of-sync...

Raf.

jimparis · Post by **jimparis** » Tue Mar 13, 2007 7:45 am

raf wrote:Also, I believe you should commit the changes to the newlib-psp directory, not only to the patch file. As now they are out-of-sync...

Agreed, except the newlib-psp directory is still against newlib 1.13 isn't it? Monsti, you really need to make a proper branch if you want to be developing a new set of newlib patches in parallel, or at least tag off what we already have and replace the newlib 1.13 stuff entirely if you're sure that there are no regressions.

monsti · Post by **monsti** » Tue Mar 13, 2007 8:09 am

jimparis wrote:Monsti, you really need to make a proper branch if you want to be developing a new set of newlib patches in parallel, or at least tag off what we already have and replace the newlib 1.13 stuff entirely if you're sure that there are no regressions.

I didn't use the newlib directory. I just ported the 1.13 patch to 1.15 and added changes to that. I don't know who is responsible for the /newlib dir. But adding a simple .patch file won't hurt anybody.

There are also some experimental stuff inside 1.15 like nanosleep.

I also consider adding a AF_UNIX emulation patch. I see this as experimental playground as 1.15 isn't well tested anyway - It just compiles :)

Any better idea or suggestions?

raf · Post by **raf** » Tue Mar 13, 2007 11:53 pm

monsti wrote: I don't know who is responsible for the /newlib dir. But adding a simple .patch file won't hurt anybody.

One way of telling would be to do something like this "svn log newlib-psp | less"
In this case, I guess that would be either mrbrown or jim... I think jim's suggestion is the best approach. That is, either create a separate newlib 1.15 directory along with the current one, or create a separate branch in subversion.

Raf.

jimparis · Post by **jimparis** » Wed Mar 14, 2007 6:53 am

Also check psptoolchain/devel/README.TXT if you haven't seen it yet. It describes the reasoning behind having the separate drop-in trees, and describes how to use the scripts that mrbrown provided to manage them. The big benefit of this over just modifying the patches directly is that it's a lot easier to make and test changes, especially when they're being worked on by multiple people.