| View previous topic :: View next topic |
| Author |
Message |
fraca7
Joined: 03 Oct 2005
Posts: 21
Location: Paris
|
 Posted: Sun Mar 04, 2007 9:20 pm Post subject: Resolver hang |
 |
|
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 |
|
| Back to top |
|
 |
fraca7
Joined: 03 Oct 2005
Posts: 21
Location: Paris
|
| Posted: Sat Mar 10, 2007 8:39 pm Post subject: |
|
|
| This seems to be fixed if I add sceNetResolverStop() in gethostbyname. Should I commit the fix ? Who's "in charge" of newlib ? |
|
| Back to top |
|
|
monsti
Joined: 04 Mar 2007
Posts: 13
Location: Germany
|
| Posted: Sun Mar 11, 2007 12:38 am Post subject: |
|
|
| 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.
_________________
Bye,
Monsti |
|
| Back to top |
|
|
monsti
Joined: 04 Mar 2007
Posts: 13
Location: Germany
|
| Posted: Sun Mar 11, 2007 3:28 am Post subject: |
|
|
Ok this is patched in the newlib.1.15.0.patch in the toolchainn SVN.
_________________
Bye,
Monsti |
|
| Back to top |
|
|
raf
Joined: 13 Oct 2005
Posts: 57
|
| Posted: Tue Mar 13, 2007 12:11 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
jimparis
Joined: 10 Jun 2005
Posts: 1179
Location: Boston
|
| Posted: Tue Mar 13, 2007 7:45 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
monsti
Joined: 04 Mar 2007
Posts: 13
Location: Germany
|
| Posted: Tue Mar 13, 2007 8:09 am Post subject: |
|
|
| 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?
_________________
Bye,
Monsti |
|
| Back to top |
|
|
raf
Joined: 13 Oct 2005
Posts: 57
|
| Posted: Tue Mar 13, 2007 11:53 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
jimparis
Joined: 10 Jun 2005
Posts: 1179
Location: Boston
|
| Posted: Wed Mar 14, 2007 6:53 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
