LMPX.COM |
Home | Linux | Mysql | PHP | XML | ||
|
|
|||
From: Joshua Juran Date: Fri Jul 22 01:42:55 2005 Subject: Re: Porting perl to (traditional) Mac OS via Genie
I would like to add my work to the core (when it's ready) as a new platform. Unless anyone objects, the platform name is 'Lamp', unix-name 'lamp', custom header 'lampish.h', and preprocessor macro MACOS_LAMP. On Jul 19, 2005, at 11:31 AM, Joshua Juran wrote: > On Jul 19, 2005, at 5:43 AM, Dominic Dunlop wrote: > >> Good to hear. You don't say whether this is PPC or 68k Mac OS. I >> guess the former, though the FAQs on your site make me wonder. > > Genie requires CFM... > Genie's sockets support requires Open Transport ... I forgot to mention -- Genie builds and runs both as Carbon and classic. I typically develop in OS X using Carbon, running either natively or in Classic. >> MachTen was delivered with gcc, so I didn't use MPW or CodeWarrior in >> porting perl. If you search in old perl5- >> porters archives, you'll find mail about various issues I tripped >> over, including malloc() (once tweaked to work, Perl's own malloc was >> much faster than Mac OS' own); and fork() (MachTen, thanks to deep >> and probably dark magic, has both fork() and vfork(), but the latter >> is MUCH faster, as Mac OS does not support Copy on Write). You'll >> also find clues in hints/machten.sh. Mac OS doesn't have a malloc(), per se. It has NewPtr(), which is a dreadfully bad substitute, and the standard C library has one. I don't know how MSL's malloc() compares to MPW's. > One of the problems is returning twice. Matthias got the idea to > provide vfork() as a macro that calls setjmp(), which he implemented > in his Natty project.[2] I opted against this for now, since what > you'd have to do with the return value of setjmp() to implement proper > vfork() semantics and what the standard says you're allowed to do with > it are not compatible. AFAICT you're not even allowed to assign the > return value to a variable. It might work anyway, but I didn't wish > to go there. > > My interim solution requires as a compromise that code be written thus: [snip] > The trick here is that for a Genie plugin, vfork() saves the caller's > process context and returns the child pid (once), is_child_pid() is > the identity function (always true for a pid), and either execve() > (unless it fails) or _exit() restores the original process context AND > RETURNS. (Unless you call without forking, in which case it > terminates the caller's thread.) > > Hey -- it works, doesn't it? For trivial uses, yes, but perl's code is rather more involved. I revisited Matthias' Natty project -- he writes: #define vfork() setjmp( *NattyVFork() ) NattyVFork() dynamically allocates and returns a jmp_buf* which is dereferenced and passed to setjmp(). One problem with this is that there's no way to return -1 on failure. I did this: #define vfork() ( SpawnVFork() ? -1 : setjmp(gVfork_jmp_buf) ) SpawnVFork() does almost the same thing that my old vfork() did, but returns 0 on success. Genie programs have private globals, so we can use a global for the jmp_buf. Execve() and _exit() save getpid(), call their respective kernel routines, and (for execve(), if successful) longjmp() with the saved pid. The standard library makes very weak guarantees about setjmp(), but fortunately Metrowerks delivers what we need. We now have a working 'system' operator. Josh -- Joshua Juran Metamage Software Creations - Mac Software and Consulting http://www.metamage.com/ * Creation at the highest state of the art *
| Navigate in group perl.macperl.porters at sever nntp.perl.org | |
| Previous | Next |
| © No Copyright You are free to use Anything |
Site Maintained by PHP Developer
Powered By PHP Consultants |